Package: libopenmpt0
Version: 0.2.7386~beta20.3-3+deb9u2
Severity: important
Dear Maintainer,
Using this shared library with external application creates segfault
with memcopy related functions.
This can be avoided if one would recompile with -O3 optimization as actually
does upstream in the
Hi,
On 07/03/18 14:32, s3rj1k wrote:
> Package: libopenmpt0
> Version: 0.2.7386~beta20.3-3+deb9u2
> Severity: important
>
> Dear Maintainer,
>
> Using this shared library with external application creates segfault
> with memcopy related functions.
I'm not sure I understand what you mean.
Do
Hi,
On 07/03/18 15:13, Серж ИвановЪ wrote:
> Attached additional info, core dump and gdb backtrace log
Thanks, although I can't read the core dump without the binaries it runs
from. Can you reproduce the bug using binaries only found in the Debian
archive?
James
signature.asc
Description: Ope
Unfortunately freeswitch (the actual application) is not available in deb
archive.
How can I provide addition info on this issue?
On 07/03/18 15:58, Серж ИвановЪ wrote:
> Unfortunately freeswitch (the actual application) is not available in
> deb archive.
>
> How can I provide addition info on this issue?
It would be useful to know what in libopenmpt was causing this.
Can you add this to your APT sources.list:
deb http://d
Attached full bt log of gdb and valgrind log with debug-symbols package
installed
Unfortunately can't test this with other applications (ffmpeg ...)
bt.tar.gz
Description: application/gzip
Am Mittwoch, den 07.03.2018, 09:32 -0500 schrieb s3rj1k:
> Using this shared library with external application creates segfault
> with memcopy related functions.
Since you are mentioning memcpy(), maybe the code calls it with
overlapping source and destination pointers and -O3 optimizes this to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Wed, 07 Mar 2018 22:23:34 +0100
Source: python-midiutil
Binary: python-midiutil python3-midiutil python-midiutil-doc
Architecture: source
Version: 1.2.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Multimedia Maintain
python-midiutil_1.2.1-1_source.changes uploaded successfully to localhost
along with the files:
python-midiutil_1.2.1-1.dsc
python-midiutil_1.2.1.orig.tar.gz
python-midiutil_1.2.1-1.debian.tar.xz
python-midiutil_1.2.1-1_amd64.buildinfo
Greetings,
Your Debian queue daemon (running
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Wed, 07 Mar 2018 22:23:34 +0100
Source: python-midiutil
Binary: python-midiutil python3-midiutil python-midiutil-doc
Architecture: source
Version: 1.2.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Multim
I’m still working on a complete stand alone example but the way to reproduce
this is to dlopen a module that is linked to libavformat. It does not require
any code at all related to libavformat to be executed at all, or any includes
to libavformat, or anything at all related to apt, just the li
Confirmed its the same linking to JUST libopenmpt, without libavformat
The problem appears to be a large stack allocation in a static initializer when
using constrained stack sizes. This issue appears to be fixed in upstream
openmpt, we are testing a back port of this patch now to confirm. it appears
the optimizer changes this from a stack allocation at -O3, but
confirmed steps to reproduce the issue in the simplest way:
# ulimit -s 240 && openmpt123
Segmentation fault
The issue can be fixed using 2 upstream patches:
https://github.com/OpenMPT/openmpt/commit/6f8f7be5848be8c4487b1779c332b802674f6747.patch
https://github.com/OpenMPT/openmpt/commit/133007530cbe737f4b56db907aa6baee0ea5b17d.patch
applied to sources in this order, after recompile no segmentation fau
15 matches
Mail list logo
