GNOME Bugzilla – Bug 633836
rhythmbox 0.13.x quits with "Segmentation fault" message.
Last modified: 2011-10-21 03:03:58 UTC
Created attachment 173702 [details] the output of stack trace of rhythmbox About 1 out of 10 times I execute rhythmbox, rhythmbox generates segmentation fault message and quits. I attached the output of strace rhythmbox. The system is slackware64-current, and kernel is 2.6.35.4.
Thanks for taking the time to report this bug. Without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Created attachment 174672 [details] strace rhythmbox I recompiled rhythmbox 0.13.2 and all of its dependencies deep down the dependency tree with -ggdb option. This is the output of "strace rhythmbox > rhythmbox.txt 2>&1". Enjoy reading it.
strace output is not the same thing as a stack trace, and it's not helpful in this case.
Created attachment 174689 [details] stack trace of rhythmbox obtained from gdb This is the stack trace of rhythmbox from gdb. I hope you get something out of this.
This looks like a problem with libxml2 and/or zlib. Please provide a new stack trace including debug symbols for both of those.
Created attachment 174819 [details] rhythmbox stack trace from gdb with zlib and libxml2 debugging symbols I rebuilt zlib and libxml2 with debugging symbols and obtained the stack trace again. This one seems informative.
Thanks, that seems to show where the problem is..
+ Trace 224748
The pointer is obviously being mangled somewhere along the line, but I can't see where.
ugh, thanks, stack trace parser.. gzdirect (file=0xffffffffe0015490) is the interesting thing.
Reassigning to libxml2 since that seems a bit more likely than zlib to be where the problem lies.
http://mail.gnome.org/archives/xml/2010-November/msg00030.html this problem is really unclear. We have seen this only on users where libxml2 was recompiled locally instead of using a distro build so far, and we are wondering if this isn't a problem of zlib.h headers differences which triggers this. => in a nutshell this problem appeared only a few times and we still don't know where it comes from Daniel
This problem happened with libxml2 distro build, too.
When I installed zlib xmlReadFile began to crash, identical to reported here: http://mail.gnome.org/archives/xml/2010-April/msg00008.html Removing libzlib and relinking Openbox against libxml2 resolved the crash. Clearly the bug is in libxml2, and only appears when zlib is present in the system. zlib-1.2.5 libxml2-2.7.6.dfsg-1ubuntu1.2 My backtrace for good measure:
+ Trace 228854
(gdb) l 151 path = g_build_filename(it->data, domain, filename, NULL); 152 153 if (stat(path, &s) >= 0) { 154 /* XML_PARSE_BLANKS is needed apparently, or the tree can end up 155 with extra nodes in it. */ 156 i->doc = xmlReadFile(path, NULL, (XML_PARSE_NOBLANKS | 157 XML_PARSE_RECOVER)); 158 xmlXIncludeProcessFlags(i->doc, (XML_PARSE_NOBLANKS | 159 XML_PARSE_RECOVER)); 160 if (i->doc) { (gdb) print path $1 = (gchar *) 0x4db0e0 "/usr/local/google/home/danakj/.config/openbox/rc"
It's clear from the upstream work that libxml2 was using a structure from zlib which wasn't supposed to be public. the accessor for the information was added nearly at the same time as the structure got changed. So libxml2 (and application embedding libxml2 in their code) and zlib *must* be updated in tandem. If libxml2 is the old version ro compiled against the old version of zlib and you update the zlib independantly it will crash. It's sad but there is no way around it. Do not update one without the other, the distro are aware and are being careful about the issue. But if you update components in isolation, you take the risk and need to assume it, there is unfortunately nothing I can do to prevent the issue ! Daniel