Bug#689659: mpg123 segfaults on specific file

[Thomas Orgis]

Am Sat, 6 Oct 2012 13:07:55 +0200
schrieb Pavel Machek <pavel at ucw.cz>: 

> What is "the infamous memcpy optimization"? I tried brief google, but
> nothing. This? http://lwn.net/Articles/417881/ It has no details :-(.

Yeah, I am talking of the change referred to there. Damn, this is a
long time ago already. Software _should_ have catched up with the
enforced memcpy() behaviour ...

> pavel at amd:/tmp$ valgrind mpg123 mp3.bug/cut.mp3 

Ah, this is an AMD box. So this could be the 3DNow(ext) code ... I
could fire up an Athlon XP with debian squeeze and update it ... but
not anyday soon. I don't have 32 bit AMD systems hanging around
connected. I don't see 

> ==18936== Process terminating with default action of signal 11
> (SIGSEGV): dumping core
> ==18936==  Bad permissions for mapped region at address 0x805EFFC
> ==18936==    at 0x4028E3C: memcpy (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
> ==18936==    by 0x804D322: ??? (in /usr/local/bin/mpg123)
> ==18936== Invalid read of size 1
> ==18936==    at 0x4008D11: check_match.8610 (dl-lookup.c:134)
> ==18936==    by 0x400936A: do_lookup_x (dl-lookup.c:273)
> ==18936==    by 0x4009661: _dl_lookup_symbol_x (dl-lookup.c:729)
> ==18936==    by 0x400DC15: _dl_fixup (dl-runtime.c:119)
> ==18936==    by 0x40139BF: _dl_runtime_resolve (dl-trampoline.S:37)
> ==18936==    by 0x4035E0F: ??? (in /tmp/mp3.bug/cut.mp3)
> ==18936==    by 0x804D322: ??? (in /usr/local/bin/mpg123)
> ==18936==  Address 0x1eb is not stack'd, malloc'd or (recently) free'd

... as that does not make a lot of sense anyway (the input file is in
the call trace??). I installed a wheezy system in qemu-kvm and could
not reproduce the crash.

But I got 1.14.4-1 there, not 1.14.2+svn20120622-1. Do you see the
crash with the updated package? Suspecting one of the assembly
decoders, I noticed that the debian build of mpg123 is fixed to the
i486 one:

shell$ mpg123 --list-cpu
builtin decoders: i486

Is that intentional? This is just some C code with quirks to please the
i486 CPU, not necessarily of any benefit on other x86 cores. Generic of
i386 should be preferred. But most of all: For sensible performance,
one should use the multi-cpu default build (--with-cpu=x86 on 32 bit
systems). I suspect that Pavel's crash could be related to using
3DNow(ext).

Pavel, what does 

sh$ mpg123 --test-cpu

report for you? And also, what does

sh$ mpg123 -v some_file.mp3 2>&1 | grep Decoder

show? It naturally just says 'Decoder: i486' here. If you have a
multi-cpu build, please test some of the other available cpu opts
(mpg123 --cpu generic; mpg123 --cpu mmx, mpg123 --cpu i386, mpg123
--cpu sse; etc). 


Alrighty then,

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20121008/5996f0b1/attachment-0001.pgp>