GNOME Bugzilla – Bug 621657
constant segfaults in gslice.c
Last modified: 2010-06-21 05:01:11 UTC
I'm running 2.30.2 from Ubuntu Lucid, and getting a number of segfaults, sometimes a few a day, all in gslice.c. I'm currently running with G_SLICE=debug-blocks to see if that results in anything useful, but it hasn't segfaulted again since setting that. No other GTK+ apps are exhibiting this, and I'm pretty sure Epiphany 2.30.0 didn't either (although I can't remember if there was a webkitgtk upgrade at the same time as the upgrade to 2.30.2. epiphany-browser 2.30.2-1ubuntu1.1 epiphany-extensions 2.30.0-4 libwebkit-1.0-2 1.2.0-1 libgtk2.0-0 2.20.1-0ubuntu1 libglib2.0-0 2.24.1-0ubuntu1 A typical stack trace looks like:
+ Trace 222420
(In reply to comment #0) > I'm running 2.30.2 from Ubuntu Lucid, and getting a number of segfaults, > sometimes a few a day, all in gslice.c. I'm currently running with > G_SLICE=debug-blocks a better approach would be to just run under valgrind, with G_SLICE=always-malloc, and see what it complains about
Created attachment 163769 [details] valgrind log Oh, okay. I just running under valgrind with some help from http://live.gnome.org/Valgrind: > G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --log-file=vgdump --suppressions=gtk.suppression epiphany-browser -p --profile=ephy Valgrind log is attached. It ended up getting killed, seemingly under the same cirmstances, and while there's a lot of possible leaks in gslice.c, nothing comes up for magazine_chain_pop_head (which is where the segfault always happens) and I can't see anything else that might be useful. I'm not familiar with valgrind though so I might be missing it. The last few lines output on the terminal were: > ** (epiphany:22607): CRITICAL **: void webkit_download_set_destination_uri(WebKitDownload*, const gchar*): assertion `destination_uri' failed > > ** (epiphany:22607): CRITICAL **: void webkit_download_start(WebKitDownload*): assertion `priv->destinationURI' failed > Killed But I'm not sure if that is related.
The problem isn't in gslice; if it's crashing inside gslice, that means some other piece of code somewhere is mistakenly scribbling over gslice's bookkeeping information, and then the next time gslice tries to malloc or free something, it ends up reading garbage and crashing. In your trace, the only Invalid write valgrind is seeing is: ==22607== Invalid write of size 8 ==22607== at 0x7A4EA44: JSC::JIT::unlinkCall(JSC::CallLinkInfo*) (X86Assembler.h:1603) ==22607== by 0x7A94477: JSC::CodeBlock::unlinkCallers() (CodeBlock.cpp:1387) ==22607== by 0x7B50AFB: JSC::JSFunction::~JSFunction() (JSFunction.cpp:93) ==22607== by 0x7B3070E: JSC::Heap::sweep() (Collector.cpp:1083) ==22607== by 0x7B33A9D: JSC::Heap::collectAllGarbage() (Collector.cpp:1279) which is to say, there's a bug in the JavaScript garbage collector... fun!
Okay, so this seems like a webkit issue then. I'll open a bug there.
Filed at: https://bugs.webkit.org/show_bug.cgi?id=40875