Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-08 Thread James Cowgill
Control: fixed -1 0.3.1-1

Hi,

On 08/03/18 00:11, Серж ИвановЪ wrote:
> 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 faults
> were encountered.
> 
> those patches can be squashed for convenience to single patch.

Thanks for this (and to Michael for the way to reproduce this). While I
agree that these patches are an improvement, I'm not convinced that they
need to be applied to stable. It seems to me there is also a bug in
freeswitch here which reduced the stack size and proceeds to dlopen some
libraries without understanding the full implications of this.

James



signature.asc
Description: OpenPGP digital signature


Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread Серж ИвановЪ
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 faults
were encountered.

those patches can be squashed for convenience to single patch.


Bug#892272:

2018-03-07 Thread Michael Jerris
confirmed steps to reproduce the issue in the simplest way:

# ulimit -s 240 && openmpt123
Segmentation fault





Bug#892272:

2018-03-07 Thread Michael Jerris
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 the explicit 
change is a better fix.


Bug#892272:

2018-03-07 Thread Michael Jerris
Confirmed its the same linking to JUST libopenmpt, without libavformat



Bug#892272: libavformat/libopenmpt failure on dlopen

2018-03-07 Thread Michael Jerris
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 linking, then 
dlopen of that so

#0  0x7fd8315fdca2 in ?? () from /usr/lib/x86_64-linux-gnu/libopenmpt.so.0
#1  0x7fd87d8b08aa in call_init (l=, argc=argc@entry=2, 
argv=argv@entry=0x7ffc0cfd1b58, env=env@entry=0x7ffc0cfd1b70) at dl-init.c:72
#2  0x7fd87d8b09bb in call_init (env=0x7ffc0cfd1b70, argv=0x7ffc0cfd1b58, 
argc=2, l=) at dl-init.c:30
#3  _dl_init (main_map=main_map@entry=0x561842c5b320, argc=2, 
argv=0x7ffc0cfd1b58, env=0x7ffc0cfd1b70) at dl-init.c:120
#4  0x7fd87d8b4f38 in dl_open_worker (a=a@entry=0x7ffc0cfcc990) at 
dl-open.c:575
#5  0x7fd87d8b0754 in _dl_catch_error 
(objname=objname@entry=0x7ffc0cfcc980, 
errstring=errstring@entry=0x7ffc0cfcc988, 
mallocedp=mallocedp@entry=0x7ffc0cfcc97f, 
operate=operate@entry=0x7fd87d8b4b50 , 
args=args@entry=0x7ffc0cfcc990) at dl-error.c:187
#6  0x7fd87d8b46e9 in _dl_open (file=0x561842bac540 
"/usr/local/freeswitch/mod/mod_commands.so", mode=-2147483646, 
caller_dlopen=0x7fd87cd637da , nsid=-2, argc=, argv=, env=0x7ffc0cfd1b70) at dl-open.c:660
#7  0x7fd87c67cee9 in dlopen_doit (a=a@entry=0x7ffc0cfccbc0) at dlopen.c:66
#8  0x7fd87d8b0754 in _dl_catch_error (objname=0x561842b78930, 
errstring=0x561842b78938, mallocedp=0x561842b78928, operate=0x7fd87c67ce90 
, 
args=0x7ffc0cfccbc0) at dl-error.c:187
#9  0x7fd87c67d531 in _dlerror_run (operate=operate@entry=0x7fd87c67ce90 
, args=args@entry=0x7ffc0cfccbc0) at dlerror.c:163
#10 0x7fd87c67cf82 in __dlopen (file=, mode=mode@entry=2) at 
dlopen.c:87



Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread Fabian Greffrath
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
call memmove() instead?

 - Fabian


signature.asc
Description: This is a digitally signed message part


Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread Серж ИвановЪ
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


Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread James Cowgill
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://deb.debian.org/debian-debug/ stretch-debug main

Then run "apt update; apt install libopenmpt0-dbgsym"

If you generate your backtrace with gdb now, it should tell you what in
libopenmpt triggered the bug.

Running freeswitch inside valgrind might show some issues.

Do other programs which use libopenmpt work - like ffmpeg and openmpt123?

James



signature.asc
Description: OpenPGP digital signature


Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread Серж ИвановЪ
Unfortunately freeswitch (the actual application) is not available in deb
archive.

How can I provide addition info on this issue?


Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread James Cowgill
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: OpenPGP digital signature


Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread James Cowgill
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 you have any logs? A stack backtrace? Specifically what commands do
you run to get the segfault?

>  This can be avoided if one would recompile with -O3 optimization as actually
>  does upstream in their makefile (not autotool sources)
> 
>  Adding this to rules effectively fixes issue:
> 
>  export DEB_CXXFLAGS_MAINT_APPEND = -O3

If this flag genuinely does fix the segfault, then there's likely some
undefined behavior in libopenmpt which the compiler is exploiting and
your suggested fix would just hide the real bug.

Thanks,
James



signature.asc
Description: OpenPGP digital signature


Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application

2018-03-07 Thread s3rj1k
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 their makefile (not autotool sources)

 Adding this to rules effectively fixes issue:

 export DEB_CXXFLAGS_MAINT_APPEND = -O3

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libopenmpt0 depends on:
ii  libc6   2.24-11+deb9u1
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libmpg123-0 1.23.8-1+b1
ii  libstdc++6  6.3.0-18+deb9u1
ii  libvorbis0a 1.3.5-4+deb9u1
ii  libvorbisfile3  1.3.5-4+deb9u1
ii  zlib1g  1:1.2.8.dfsg-5

libopenmpt0 recommends no packages.

libopenmpt0 suggests no packages.

-- no debconf information