Bug#651636: libwebkitgtk-1.0-0: GtkLauncher crashes while browsing websites

Federico Bruni fedelogy at gmail.com
Sat Apr 28 11:33:33 UTC 2012


2012/4/28 Steven Chamberlain <steven at pyro.eu.org>:
> But that is not a webkit issue;  it was reported in libxi6 as #636920
> and recently fixed.
>
> I still think the original issue you reported was a webkit bug, but you
> may need to upgrade libxi6 to get clean backtraces.
>

I've pinned the version in unstable

>
> On Lemote Yeeloong (with limited RAM and slow disk I/O) it might be
> easier to run GtkLauncher not within gdb, but enable core dumping;  then
> it will start up and run much faster, and you can produce a backtrace
> from the core file later.

Here's what I've done (as normal user):

ulimit -c 50000
/usr/lib/webkitgtk-3.0-0/libexec/GtkLauncher

The program crashed immediately and I got a core file.

Here's the backtrace (hope it's correct):

$ gdb /usr/lib/webkitgtk-3.0-0/libexec/GtkLauncher core
GNU gdb (GDB) 7.4-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mipsel-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/usr/lib/webkitgtk-3.0-0/libexec/GtkLauncher...Reading symbols from
/usr/lib/debug/usr/lib/webkitgtk-3.0-0/libexec/GtkLauncher...done.
done.
[New LWP 1052]
[New LWP 1054]
[New LWP 1055]
[New LWP 1056]
[New LWP 1057]
[New LWP 1059]
[New LWP 1069]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/webkitgtk-3.0-0/libexec/GtkLauncher'.
Program terminated with signal 11, Segmentation fault.
#0  0x75c56508 in JSC::FunctionExecutable::clearCode (this=0x67967920)
    at ../Source/JavaScriptCore/runtime/Executable.cpp:565
565	../Source/JavaScriptCore/runtime/Executable.cpp: No such file or directory.
(gdb) bt
#0  0x75c56508 in JSC::FunctionExecutable::clearCode (this=0x67967920)
    at ../Source/JavaScriptCore/runtime/Executable.cpp:565
#1  0x75c707e0 in JSC::JSGlobalData::recompileAllJSFunctions (this=0x373)
    at ../Source/JavaScriptCore/runtime/JSGlobalData.cpp:445
#2  0x75b7c95c in JSC::Heap::collectAllGarbage (this=0x729cc6f0) at
../Source/JavaScriptCore/heap/Heap.cpp:651
#3  0x76a45f04 in WebCore::collect () at
../Source/WebCore/bindings/js/GCController.cpp:40
#4  0x770f1a4c in WebCore::ThreadTimers::sharedTimerFiredInternal
(this=0x729a2018)
    at ../Source/WebCore/platform/ThreadTimers.cpp:97
#5  0x77aa6d30 in WebCore::timeout_cb () at
../Source/WebCore/platform/gtk/SharedTimerGtk.cpp:47
#6  0x75f9e520 in ?? () from /lib/mipsel-linux-gnu/libglib-2.0.so.0
warning: GDB can't find the start of the function at 0x75f9e51e.

    GDB is unable to find the start of the function at 0x75f9e51e
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x75f9e51e for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
(gdb) bt
#0  0x75c56508 in JSC::FunctionExecutable::clearCode (this=0x67967920)
    at ../Source/JavaScriptCore/runtime/Executable.cpp:565
#1  0x75c707e0 in JSC::JSGlobalData::recompileAllJSFunctions (this=0x373)
    at ../Source/JavaScriptCore/runtime/JSGlobalData.cpp:445
#2  0x75b7c95c in JSC::Heap::collectAllGarbage (this=0x729cc6f0) at
../Source/JavaScriptCore/heap/Heap.cpp:651
#3  0x76a45f04 in WebCore::collect () at
../Source/WebCore/bindings/js/GCController.cpp:40
#4  0x770f1a4c in WebCore::ThreadTimers::sharedTimerFiredInternal
(this=0x729a2018)
    at ../Source/WebCore/platform/ThreadTimers.cpp:97
#5  0x77aa6d30 in WebCore::timeout_cb () at
../Source/WebCore/platform/gtk/SharedTimerGtk.cpp:47
#6  0x75f9e520 in ?? () from /lib/mipsel-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0  0x75c56508 in JSC::FunctionExecutable::clearCode (this=0x67967920)
    at ../Source/JavaScriptCore/runtime/Executable.cpp:565
#1  0x75c707e0 in JSC::JSGlobalData::recompileAllJSFunctions (this=0x373)
    at ../Source/JavaScriptCore/runtime/JSGlobalData.cpp:445
#2  0x75b7c95c in JSC::Heap::collectAllGarbage (this=0x729cc6f0) at
../Source/JavaScriptCore/heap/Heap.cpp:651
#3  0x76a45f04 in WebCore::collect () at
../Source/WebCore/bindings/js/GCController.cpp:40
#4  0x770f1a4c in WebCore::ThreadTimers::sharedTimerFiredInternal
(this=0x729a2018)
    at ../Source/WebCore/platform/ThreadTimers.cpp:97
#5  0x77aa6d30 in WebCore::timeout_cb () at
../Source/WebCore/platform/gtk/SharedTimerGtk.cpp:47
#6  0x75f9e520 in ?? () from /lib/mipsel-linux-gnu/libglib-2.0.so.0
(gdb)





More information about the Pkg-webkit-maintainers mailing list