abrt version: 1.1.14 architecture: x86_64 Attached file: backtrace cmdline: audacious2 component: audacious executable: /usr/bin/audacious2 kernel: 2.6.37-2.fc15.x86_64 package: audacious-2.4.3-1.fc15 reason: Process /usr/bin/audacious2 was killed by signal 11 (SIGSEGV) release: Fedora release 15 (Rawhide) time: 1295103978 uid: 500 comment ----- just invoke from gnome menu. If from a gnome terminal, see this: Segmentation fault (core dumped) How to reproduce ----- 1. install audacious on rawhide on 20110115 2. invoke from gnome menu 3.
Created attachment 473646 [details] File: backtrace
The backtrace you attached is useless because it's missing too many debuginfo packages. Can you please try to refresh it in ABRT (or after running "debuginfo-install audacious-plugins audacious" as root)? > #0 0x00007f1a2e7d4628 in ?? () from /usr/lib64/audacious/Input/adplug.so So, it crashed somewhere in the Adplug plugin, which hasn't changed compared with the previous build (2.4.2).
Created attachment 473671 [details] backtrace with more debuginfos
Looks like libstdc++ breakage to me - unless the adplug code does something nasty in C++ that would no longer be okay in Rawhide. Can reproduce with a fresh install of Rawhide (x86_64), but not with F14 (i686).
Some observations [albeit clueless yet]: * last GCC package set update in Rawhide is from Nov 30th, which is _before_ the last build of Audacious (2.4.2) on Dec 9th * downgrading to audacious-plugins-2.4.2-1.fc15 from Dec 9th works: http://koji.fedoraproject.org/koji/buildinfo?buildID=208615 * the adplug source between audacious-plugins 2.4.2 and 2.4.3 has not changed, the entire diff is just 18k * rebuilding both audacious + audacious-plugins 2.4.2-1.fc15 from Dec 9th with Rawhide (20110115) also segfaults at run-time => something after Dec 9th must be the culprit * from the working koji builds from Dec 9th, rebuilding just audacious-plugins-2.4.2-1.fc15 on today's Rawhide segfaults, too
(In reply to comment #2) > The backtrace you attached is useless because it's missing too many debuginfo > packages. Can you please try to refresh it in ABRT (or after running > "debuginfo-install audacious-plugins audacious" as root)? > > > #0 0x00007f1a2e7d4628 in ?? () from /usr/lib64/audacious/Input/adplug.so > > So, it crashed somewhere in the Adplug plugin, which hasn't changed compared > with the previous build (2.4.2). You are far more adept at debugging than I, so I will assume needinfo is satisfied. BTW, abrt usually tells you what debuginfo to install, but hasn't been doing this recently.
Haven't found anything concrete, so taking this ticket back for now and trying to find out whether there's sporadic memory corruption somewhere that would not be visible from time to time.
// gcc $(pkg-config --cflags --libs gmodule-2.0) so_open.c -o so_open // requires: audacious-plugins-2.4.3-1.fc15.x86_64.rpm // http://koji.fedoraproject.org/koji/buildinfo?buildID=214193 #include <stdlib.h> #include <gmodule.h> int main(int argc, char** argv) { GModule *m; m = g_module_open("/usr/lib64/audacious/Input/adplug.so",G_MODULE_BIND_LAZY | G_MODULE_BIND_LOCAL); g_module_close(m); exit(0); } Shortest test-case I'm continueing with. (Using libdl/dlopen instead of gmodule also crashes, fwiw.) Wonder whether there's illegal C++ in adplug.so which may have worked so far only coincidentally (e.g. including Fedora 14)? The code initializes a few static const class members, one time it inherits from std::list, and all that is related to the backtrace as well.
audacious no longer crashes for me with the latest libstdc++-4.6.0-0.6.fc15.x86_64 -- and that test script returns an exit status of 0. I still get this on stderr, though: (process:19302): GModule-CRITICAL **: g_module_close: assertion `module != NULL' failed
To run the test in recent Rawhide you need to "yum -y install audacious-plugins-adplug" since the crashing plugin has been moved out into its own subpackage (not just because it crashed, but also because it has a very small target group).
*** Bug 676246 has been marked as a duplicate of this bug. ***
This code is relying on the static class member CAdPlug::players (declared in core/adplug.h and defined in core/adplug.cxx) to get initialized before the file-scope static variable conf in adplug-xmms.cc. Initialization order of global and static variables in C++ is not defined, in particular, the compiler will not automatically figure out the dependencies to initialize stuff in the correct order. This code has a 50% chance of working, it's just luck that it worked so far.
Thanks, Kevin! That and skimming over [basic.stc.static] and [stmt.dcl] in the C++ Standard sounds plausible. I've missed the cross-dependency between the two translation units and have only noticed that the code appears to be convoluted.
audacious-plugins-2.4.3-9.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/audacious-plugins-2.4.3-9.fc15
audacious-plugins-2.4.3-10.fc15 has been pushed to the Fedora 15 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update audacious-plugins'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/audacious-plugins-2.4.3-10.fc15
audacious-2.4.4-1.fc15,audacious-plugins-2.4.4-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/audacious-2.4.4-1.fc15,audacious-plugins-2.4.4-1.fc15
audacious-2.4.4-1.fc15, audacious-plugins-2.4.4-1.fc15 has been pushed to the Fedora 15 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update audacious audacious-plugins'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/audacious-2.4.4-1.fc15,audacious-plugins-2.4.4-1.fc15
audacious-2.4.4-1.fc15, audacious-plugins-2.4.4-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.