Today's update of audacious to version 2.4_beta1 although it didn't help with the most mysterious bug in the world (289513) it bringed new bugs that made it totally unstable. When trying to add some of the mp3's to a playlist it crashes. I tried to observe it on valgdind, all I saw was: ==10306== Thread 3: ==10306== Invalid read of size 1 ==10306== at 0x40ED46F: ??? (in /usr/lib/libaudtag.so.1.0.0) ==10306== by 0x40EDA4A: ??? (in /usr/lib/libaudtag.so.1.0.0) ==10306== by 0x40E960E: tag_tuple_read (in /usr/lib/libaudtag.so.1.0.0) ==10306== by 0x7611684: ??? (in /usr/lib/audacious/Input/madplug.so) ==10306== by 0x805FE97: ??? (in /usr/bin/audacious2) ==10306== by 0x805AEE2: ??? (in /usr/bin/audacious2) ==10306== by 0x4179CDE: ??? (in /usr/lib/libglib-2.0.so.0.2200.5) ==10306== by 0x4957AEE: start_thread (in /lib/libpthread-2.11.2.so) ==10306== by 0x4A7024D: clone (in /lib/libc-2.11.2.so) ==10306== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==10306==. ==10306==. ==10306== Process terminating with default action of signal 11 (SIGSEGV) ==10306== Access not within mapped region at address 0x0 ==10306== at 0x40ED46F: ??? (in /usr/lib/libaudtag.so.1.0.0) ==10306== by 0x40EDA4A: ??? (in /usr/lib/libaudtag.so.1.0.0) ==10306== by 0x40E960E: tag_tuple_read (in /usr/lib/libaudtag.so.1.0.0) ==10306== by 0x7611684: ??? (in /usr/lib/audacious/Input/madplug.so) ==10306== by 0x805FE97: ??? (in /usr/bin/audacious2) ==10306== by 0x805AEE2: ??? (in /usr/bin/audacious2) ==10306== by 0x4179CDE: ??? (in /usr/lib/libglib-2.0.so.0.2200.5) ==10306== by 0x4957AEE: start_thread (in /lib/libpthread-2.11.2.so) ==10306== by 0x4A7024D: clone (in /lib/libc-2.11.2.so) ==10306== If you believe this happened as a result of a stack ==10306== overflow in your program's main thread (unlikely but ==10306== possible), you can try to increase the size of the ==10306== main thread stack using the --main-stacksize= flag. ==10306== The main thread stack size used in this run was 8388608. ==10306==. ==10306== HEAP SUMMARY: ==10306== in use at exit: 4,152,565 bytes in 54,143 blocks ==10306== total heap usage: 972,488 allocs, 918,345 frees, 284,011,619 bytes allocated ==10306==. ==10306== LEAK SUMMARY: ==10306== definitely lost: 143,720 bytes in 7,073 blocks ==10306== indirectly lost: 31,380 bytes in 1,551 blocks ==10306== possibly lost: 2,607,792 bytes in 20,759 blocks ==10306== still reachable: 1,369,673 bytes in 24,760 blocks ==10306== suppressed: 0 bytes in 0 blocks ==10306== Rerun with --leak-check=full to see details of leaked memory ==10306==. ==10306== For counts of detected and suppressed errors, rerun with: -v ==10306== Use --track-origins=yes to see where uninitialised values come from ==10306== ERROR SUMMARY: 21 errors from 14 contexts (suppressed: 0 from 0) This reminds me old bugs experienced by windows user playing mp3 files on old WinAmp. I suggest to mark it unstable, at least on x86. Reproducible: Always Steps to Reproduce: 1. install audacious 2. get some mp3's from suspicious places, make sure they works using mplayer, mpg321 or similar things 3. add them to audacious playlist Actual Results: crash Expected Results: no crash Later I tested all these files with mplayer and mpg321, they are OK. They also could be played by previous versions of Audacious. If you wand example file, mail me directly.
Step 2. reminds me of a frequently asked question on various emulation related forums, that the standard response to was banning the user. Seriously though, while it might be something like audacious being more strict in treating mp3 tags than the other mentioned programs are, there's *no* chance of anybody doing anything without seeing those files, if only *some* files fail that way. As for bug 289513 (that seems you haven't filed upstream yet - at least your comment suggest so), it seems a local problem - perhaps a test file would help there too.
An upstream report with a "suspicious file" attached is required. The software is already marked "unstable" on X86. Neither mplayer nor mpg123/321 read ID3 tags to the level of detail that Audacious does. If you are not willing to report bugs in applications, you should not be running ~arch software in Gentoo.
