30860 2009-10-28 07:58:46 -0700 [Gtk] uzbl and surf segfaults with 1.1.15.3 and 1.1.16 (devel) 2012-04-19 23:23:23 -0700 1 1 1 Unclassified WebKit WebKitGTK 528+ (Nightly build) PC Linux RESOLVED WORKSFORME P2 Normal --- 0 rob.manea webkit-unassigned a.butenka alex dieter jmalonzo mrobinson wnxhorizonx oldest_to_newest 158560 0 rob.manea 2009-10-28 07:58:46 -0700 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() 158575 1 a.butenka 2009-10-28 08:57:26 -0700 seems an issue of uzbl. nothing webkit related 158678 2 rob.manea 2009-10-28 13:18:09 -0700 (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. 158855 3 jmalonzo 2009-10-29 03:42:33 -0700 (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. 158893 4 rob.manea 2009-10-29 07:53:29 -0700 (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. 158898 5 a.butenka 2009-10-29 08:04:17 -0700 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 158906 6 rob.manea 2009-10-29 08:29:49 -0700 (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 158915 7 pnormand 2009-10-29 08:57:18 -0700 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 () 158921 8 rob.manea 2009-10-29 09:03:51 -0700 (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} 158924 9 rob.manea 2009-10-29 09:08:06 -0700 (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} 158926 10 rob.manea 2009-10-29 09:14:13 -0700 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 158949 11 alex 2009-10-29 10:40:19 -0700 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 :). 159132 12 rob.manea 2009-10-29 15:58:33 -0700 (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'. 168636 13 wnxhorizonx 2009-12-03 20:47:10 -0800 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 171106 14 wnxhorizonx 2009-12-12 10:53:12 -0800 (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? 549203 15 mrobinson 2012-02-03 16:04:02 -0800 This seems to be a bug in enchant? Does it still exist? I haven't heard anything about it in years. 606387 16 mrobinson 2012-04-19 23:23:23 -0700 This one seems lost to history. I'll close it anyone is still suffering from it on a recent version of WebKitGTK+ please reopen.