Bug 30860 – [Gtk] uzbl and surf segfaults with 1.1.15.3 and 1.1.16 (devel)

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: WebKitGTK

Since 1.1.15.3 the uzbl and surf browsers segfault right on startup.


Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000011 in ?? ()
(gdb) bt
#0  0x00000011 in ?? ()
#1  0xb6af7420 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0
#2  0xb6af77c1 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0
#3  0xb6af800f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#4  0xb7013fd9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#5  0x08053a0c in main (argc=3, argv=0xbffff574) at uzbl-core.c:2440


uzbl-core.c:2440 being gtk_main()

[Alexander Butenko]

seems an issue of uzbl. nothing webkit related

(In reply to comment #1)
> seems an issue of uzbl. nothing webkit related

I certainly don't exclude the possibily that this is somehow
uzbl related, though i wonder why it doesn't happen with
webkit <=1.1.15.2 and why surf is affected as well.

[Jan Alonzo]

(In reply to comment #2)
> (In reply to comment #1)
> > seems an issue of uzbl. nothing webkit related
> 
> I certainly don't exclude the possibily that this is somehow
> uzbl related, though i wonder why it doesn't happen with
> webkit <=1.1.15.2 and why surf is affected as well.

Without a backtrace that's related to WebKit, it would be difficult for us to find out what's going wrong.

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > seems an issue of uzbl. nothing webkit related
> > 
> > I certainly don't exclude the possibily that this is somehow
> > uzbl related, though i wonder why it doesn't happen with
> > webkit <=1.1.15.2 and why surf is affected as well.
> 
> Without a backtrace that's related to WebKit, it would be difficult for us to
> find out what's going wrong.

I built 1.1.16 with debugging symbols, though the backtrace doesn't give more
info than what i've already posted.

Another thing that makes me pretty sure this issue is webkit related is that
all the test programs (including unit tests) do also segfault in the exact
same glib function.

[Alexander Butenko]

avb@ds:~/work$ git clone git://github.com/Dieterbe/uzbl.git
Initialized empty Git repository in /home/avb/work/uzbl/.git/
remote: Counting objects: 7299, done.
remote: Compressing objects: 100% (2776/2776), done.
remote: Total 7299 (delta 4530), reused 6857 (delta 4253)
Receiving objects: 100% (7299/7299), 1.52 MiB | 95 KiB/s, done.
Resolving deltas: 100% (4530/4530), done.
avb@ds:~/work$ cd uzbl/
avb@ds:~/work/uzbl$ ls
AUTHORS  config.h  docs  examples  LICENSE  Makefile  Makefile-new-test  misc  README  tests  uzbl.c  uzbl.h
avb@ds:~/work/uzbl$ 
avb@ds:~/work/uzbl$ 
avb@ds:~/work/uzbl$ make
cc -std=c99 -D_REENTRANT -pthread -I/usr/local/include/libsoup-2.4 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/webkit-1.0 -I/usr/include/libxml2   -ggdb -Wall -W -DARCH="\"i686\"" -lgthread-2.0 -DG_ERRORCHECK_MUTEXES -DCOMMIT="\"d2d73ad463f3d9f1c673d37457af159947b3faac\""  -fPIC -W -Wall -Wextra -pedantic -ggdb3  -pthread -L/usr/local/lib -lwebkit-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0   -pthread   uzbl.c   -o uzbl
avb@ds:~/work/uzbl$ 
avb@ds:~/work/uzbl$ 
avb@ds:~/work/uzbl$ ./uzbl 
avb@ds:~/work/uzbl$ ./uzbl http://google.com
avb@ds:~/work/uzbl$ 
avb@ds:~/work/uzbl$ ./uzbl http://google.com^C
avb@ds:~/work/uzbl$ 
avb@ds:~/work/uzbl$ 
avb@ds:~/work/uzbl$ apt-^C
(reverse-i-search)`': ^C
avb@ds:~/work/uzbl$ dpkg -l|grep webkit
ii  libwebkit-1.0-2                                1.1.16-1~kkwkt1                            Web content engine library for Gtk+
ii  libwebkit-1.0-common                           1.1.16-1~kkwkt1                            Web content engine library for Gtk+ - data f
ii  libwebkit-dev                                  1.1.16-1~kkwkt1                            Web content engine library for Gtk+ - Develo
ii  python-webkit                                  1.1.5-1                                    WebKit/Gtk Python bindings
avb@ds:~/work/uzbl$ 
avb@ds:~/work/uzbl$ ./uzbl http://google.com
avb@ds:~/work/uzbl$ 

then i see uzbl browser

(In reply to comment #5)
> [...]
> then i see uzbl browser

Odd, this doesn't work for me and many others.

Might this be a version issue with GCC, glib/gtk and webkit?

(IIRC there was/is a similar issue with GCC 4.4 and webkit
on 64bit platforms)

Anyway, for the records:
Platform 32bit
GCC      4.4.2
Webkit   1.1.16
Glib     2.22.2
Gtk      2.18.3

[Philippe Normand]

I have a similar stacktrace, on karmic too.

Program terminated with signal 11, Segmentation fault.
#0  IA__g_main_context_prepare (context=0x83c9278, priority=0xbfe07a4c) at gmain.c:2276
2276		  prepare = source->source_funcs->prepare;

Thread 4 (Thread 10112):
#0  0x00ad1422 in __kernel_vsyscall ()
#1  0x00119e15 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122
#2  0x00d5edc7 in WTF::TCMalloc_PageHeap::scavengerThread() () from /home/phil/gst/jhbuild/build/WebKit/.libs/libwebkit-1.0.so.2
#3  0x00d5ee01 in WTF::TCMalloc_PageHeap::runScavengerThread(void*) () from /home/phil/gst/jhbuild/build/WebKit/.libs/libwebkit-1.0.so.2
#4  0x0011580e in start_thread (arg=0xb6a20b70) at pthread_create.c:300
#5  0x0614c7ee in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 3 (Thread 10120):
#0  0x00ad1422 in __kernel_vsyscall ()
#1  0x06148cc8 in mmap () at ../sysdeps/unix/sysv/linux/i386/mmap.S:62
#2  0x060ed064 in new_heap (size=134236, top_pad=<value optimised out>) at arena.c:731
#3  0x060ed229 in _int_new_arena (a_tsd=0x61c13a0, size=<value optimised out>) at arena.c:907
#4  arena_get2 (a_tsd=0x61c13a0, size=<value optimised out>) at arena.c:1097
#5  0x060ef0e4 in __libc_calloc (n=2097152, elem_size=2040) at malloc.c:4019
#6  0x00a12f2c in IA__g_malloc0 (n_bytes=2040) at gmem.c:151
#7  0x00a29d41 in thread_memory_from_self (mem_size=12, mem_block=0x83d8ea0) at gslice.c:444
#8  IA__g_slice_free1 (mem_size=12, mem_block=0x83d8ea0) at gslice.c:862
#9  0x00a08ce9 in IA__g_list_free_1 (list=0x83d8ea0) at glist.c:78
#10 0x00a1c4c9 in IA__g_queue_pop_tail (queue=0x0) at gqueue.c:581
#11 0x009e5adc in g_async_queue_pop_intern_unlocked (queue=0x840a8f8, try=<value optimised out>, end_time=0xb47b7288) at gasyncqueue.c:373
#12 0x00a364e7 in g_thread_pool_wait_for_new_task (data=0x840a8c0) at gthreadpool.c:220
#13 g_thread_pool_thread_proxy (data=0x840a8c0) at gthreadpool.c:254
#14 0x00a3501f in g_thread_create_proxy (data=0x840a938) at gthread.c:635
#15 0x0011580e in start_thread (arg=0xb47b7b70) at pthread_create.c:300
#16 0x0614c7ee in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 2 (Thread 10119):
#0  0x00ad1422 in __kernel_vsyscall ()
#1  0x00119e15 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122
#2  0x08057cf7 in WTF::TCMalloc_PageHeap::scavengerThread() ()
#3  0x08057d31 in WTF::TCMalloc_PageHeap::runScavengerThread(void*) ()
#4  0x0011580e in start_thread (arg=0xb50e1b70) at pthread_create.c:300
#5  0x0614c7ee in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 1 (Thread 10098):
#0  IA__g_main_context_prepare (context=0x83c9278, priority=0xbfe07a4c) at gmain.c:2276
#1  0x00a0e011 in g_main_context_iterate (context=0x83c9278, block=<value optimised out>, dispatch=1, self=0x83a4028) at gmain.c:2571
#2  0x00a0e523 in IA__g_main_context_iteration (context=0x83c9278, may_block=1) at gmain.c:2654
#3  0x08053e04 in runTest(std::string const&) ()
---Type <return> to continue, or q <return> to quit---
#4  0x0805451e in main ()

(In reply to comment #7)
> I have a similar stacktrace, on karmic too.


Yeah, so here a trace with debug symbols in glib:

Starting program: /home/robert/proggen/uzbl/uzbl -c -
[Thread debugging using libthread_db enabled]
[New Thread 0xb4a93b70 (LWP 21641)]

Program received signal SIGSEGV, Segmentation fault.
0x00000011 in ?? ()
(gdb) bt
#0  0x00000011 in ?? ()
#1  0xb69534d0 in IA__g_main_context_prepare (context=0x809b630, priority=0xbffff3bc) at gmain.c:2280
#2  0xb6953871 in g_main_context_iterate (context=0x809b630, block=<value optimized out>, dispatch=1, self=0x805a028)
    at gmain.c:2571
#3  0xb69540bf in IA__g_main_loop_run (loop=0x80b5da0) at gmain.c:2799
#4  0xb6e9ffd9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#5  0x08054b25 in main (argc=3, argv=0xbffff584) at uzbl.c:2953
(gdb) frame 1
#1  0xb69534d0 in IA__g_main_context_prepare (context=0x809b630, priority=0xbffff3bc) at gmain.c:2280
2280		  result = (*prepare) (source, &source_timeout);
(gdb) print *source
$1 = {callback_data = 0x0, callback_funcs = 0x0, source_funcs = 0xb413a0c0, ref_count = 3, context = 0x809b630, 
  priority = 0, flags = 1, source_id = 2, poll_fds = 0x0, prev = 0x809b5c0, next = 0x80c48e8, reserved1 = 0x0, 
  reserved2 = 0x0}

(In reply to comment #8)

One thing i forgot:

print *source->source_funcs
$2 = {prepare = 0x11, check = 0x11, dispatch = 0x10, finalize = 0xffffffff, closure_callback = 0x1, closure_marshal = 0x89}

One more thing, valgrind on GtkLauncher:

$ G_SLICE=always-malloc valgrind ./GtkLauncher
==21701== Memcheck, a memory error detector
==21701== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21701== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==21701== Command: ./GtkLauncher GtkLauncher
==21701== 
==21701== Invalid read of size 4
==21701==    at 0x531348E: g_main_context_prepare (gmain.c:2276)
==21701==    by 0x5313870: g_main_context_iterate (gmain.c:2571)
==21701==    by 0x53140BE: g_main_loop_run (gmain.c:2799)
==21701==    by 0x5014FD8: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1800.3)
==21701==    by 0x8049B3C: main (main.c:209)
==21701==  Address 0x7bb40c0 is not stack'd, malloc'd or (recently) free'd
==21701== 
==21701== 
==21701== Process terminating with default action of signal 11 (SIGSEGV)
==21701==  Access not within mapped region at address 0x7BB40C0
==21701==    at 0x531348E: g_main_context_prepare (gmain.c:2276)
==21701==    by 0x5313870: g_main_context_iterate (gmain.c:2571)
==21701==    by 0x53140BE: g_main_loop_run (gmain.c:2799)
==21701==    by 0x5014FD8: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1800.3)
==21701==    by 0x8049B3C: main (main.c:209)
==21701==  If you believe this happened as a result of a stack
==21701==  overflow in your program's main thread (unlikely but
==21701==  possible), you can try to increase the size of the
==21701==  main thread stack using the --main-stacksize= flag.
==21701==  The main thread stack size used in this run was 8388608.
==21701== 
==21701== HEAP SUMMARY:
==21701==     in use at exit: 486,383 bytes in 9,761 blocks
==21701==   total heap usage: 28,253 allocs, 18,492 frees, 2,155,524 bytes allocated
==21701== 
==21701== LEAK SUMMARY:
==21701==    definitely lost: 3,468 bytes in 21 blocks
==21701==    indirectly lost: 9,567 bytes in 474 blocks
==21701==      possibly lost: 6,064 bytes in 127 blocks
==21701==    still reachable: 467,284 bytes in 9,139 blocks
==21701==         suppressed: 0 bytes in 0 blocks
==21701== Rerun with --leak-check=full to see details of leaked memory
==21701== 
==21701== For counts of detected and suppressed errors, rerun with: -v
==21701== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 192 from 13)
[1]    21701 killed     G_SLICE=always-malloc valgrind ./GtkLauncher

[Alejandro G. Castro]

I added this bug two weeks ago regarding the problem of loading zemberek twice:

http://bugzilla.abisource.com/show_bug.cgi?id=12413

I worked around the problem removing the libzembereck library of the my system :).

(In reply to comment #11)
> I added this bug two weeks ago regarding the problem of loading zemberek twice:
> 
> http://bugzilla.abisource.com/show_bug.cgi?id=12413
> 
> I worked around the problem removing the libzembereck library of the my system
> :).

I've been able to work around it by just re-compiling 
enchant with '--disable-zemberek'.

[horizonx]

I get a crash identical to Rob's on the latest version of Midori using a WebKit nightly, same gtk/gcc/glib setup except I'm on 64-bit. Going to try the workaround mentioned.

Backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb44f3700 (LWP 8491)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xb732a360 in IA__g_main_context_prepare (context=0x81cfd18, 
    priority=0xbfb971bc) at gmain.c:2280
#2  0xb732a721 in g_main_context_iterate (context=0x81cfd18, 
    block=<value optimized out>, dispatch=1, self=0x81baef0) at gmain.c:2571
#3  0xb732af6f in IA__g_main_loop_run (loop=0x81d9390) at gmain.c:2799
#4  0xb7005679 in IA__gtk_main () at gtkmain.c:1218
#5  0x08063ed6 in main (argc=1, argv=0xbfb97514) at ../midori/main.c:2106

[horizonx]

(In reply to comment #13)
> I get a crash identical to Rob's on the latest version of Midori using a WebKit
> nightly, same gtk/gcc/glib setup except I'm on 64-bit. Going to try the
> workaround mentioned.
> 
> Backtrace:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb44f3700 (LWP 8491)]
> 0x00000000 in ?? ()
> (gdb) bt
> #0  0x00000000 in ?? ()
> #1  0xb732a360 in IA__g_main_context_prepare (context=0x81cfd18, 
>     priority=0xbfb971bc) at gmain.c:2280
> #2  0xb732a721 in g_main_context_iterate (context=0x81cfd18, 
>     block=<value optimized out>, dispatch=1, self=0x81baef0) at gmain.c:2571
> #3  0xb732af6f in IA__g_main_loop_run (loop=0x81d9390) at gmain.c:2799
> #4  0xb7005679 in IA__gtk_main () at gtkmain.c:1218
> #5  0x08063ed6 in main (argc=1, argv=0xbfb97514) at ../midori/main.c:2106

It turned out that the spellcheck dictionaries on my system weren't configured properly, but the Zemberek provider always indicates that one is available even if it isn't. This is definitely an issue with Enchant and a very serious one at that -- any possible way to work around it until it gets fixed?  That provider appears to only support Turkish, so if Enchant uses Zemberek for say, en_US it seems it would be better to disable spellchecking altogether than to have a very(!) confusing segfault.  For me the repro would be to have WebKit looking for a dictionary in Enchant that isn't actually there -- could this be the case for others as well?

[Martin Robinson]

This seems to be a bug in enchant? Does it still exist? I haven't heard anything about it in years.

[Martin Robinson]

This one seems lost to history. I'll close it anyone is still suffering from it on a recent version of WebKitGTK+ please reopen.