In Debian we noticed that WebKitGTK 2.46.1 crashes on i386 when running the ruby-gnome tests. 2.46.0 seems to work fine. This is the test in question: https://github.com/ruby-gnome/ruby-gnome/blob/4.2.2/webkit2-gtk/test/test-webkit2-gtk-web-view.rb#L64 It loads an URL from a local server and waits for the "load-changed" signal. Here is the partial stack trace of the crash: ruby-gnome-4.2.2/webkit2-gtk/test/test-webkit2-gtk-web-view.rb:112: [BUG] Segmentation fault at 0x00000039 Core was generated by `ruby webkit2-gtk/test/run-test.rb'. Program terminated with signal SIGABRT, Aborted. #0 0xf7f10559 in __kernel_vsyscall () [Current thread is 1 (Thread 0xf76ccf00 (LWP 2421721))] (gdb) bt #0 0xf7f10559 in __kernel_vsyscall () #1 0xf7760a1f in __pthread_kill_implementation (threadid=threadid@entry=4151103232, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:43 #2 0xf7760a9b in __pthread_kill_internal (threadid=4151103232, signo=6) at ./nptl/pthread_kill.c:78 #3 0xf7709ef1 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26 #4 0xf76f12d5 in __GI_abort () at ./stdlib/abort.c:79 #5 0xf7b33721 in die () at ./error.c:784 #6 rb_bug_for_fatal_signal (default_sighandler=0x0, sig=11, ctx=0x57f2b34c, fmt=0xf7d6dfae "Segmentation fault at %p") at ./error.c:825 #7 0xf7cc4f24 in sigsegv (sig=11, info=0x57f2b2cc, ctx=0x57f2b34c) at ./signal.c:964 #8 0xf7f10580 in <signal handler called> () #9 operator() (__closure=0x5951fa14, condition=(G_IO_IN | G_IO_HUP)) at ./Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:266 #10 0xdc777a8a in WTF::Detail::CallableWrapper<WebKit::ProcessLauncher::launchProcess()::<lambda(GIOCondition)>, int, GIOCondition>::call(GIOCondition) (this=0x5951fa10, in#0=(G_IO_IN | G_IO_HUP)) at WTF/Headers/wtf/Function.h:53 #11 0xdb821ae8 in WTF::Function<int(GIOCondition)>::operator() (this=0x59691b94, in#0=(G_IO_IN | G_IO_HUP)) at ./Source/WTF/wtf/Function.h:82 #12 0xdb82162c in WTF::GSocketMonitor::socketSourceCallback (condition=(G_IO_IN | G_IO_HUP), monitor=0x59691b8c) at ./Source/WTF/wtf/glib/GSocketMonitor.cpp:43 #13 0xf43b7dd4 in socket_source_dispatch (source=0x5c670c30, callback=0xdb8215da <WTF::GSocketMonitor::socketSourceCallback(_GSocket*, GIOCondition, WTF::GSocketMonitor*)>, user_data=0x59691b8c) at ../../../gio/gsocket.c:4267 #14 0xf5143a4d in g_main_dispatch (context=context@entry=0x58154c90) at ../../../glib/gmain.c:3357 #15 0xf5145d75 in g_main_context_dispatch_unlocked (context=<optimized out>) at ../../../glib/gmain.c:4208 #16 g_main_context_iterate_unlocked (context=<optimized out>, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:4273 #17 0xf51468b7 in g_main_loop_run (loop=<optimized out>) at ../../../glib/gmain.c:4475 I think that the interesting part is in frame #10, see the value of m_ptr: #10 0xdc777a8a in WTF::Detail::CallableWrapper<WebKit::ProcessLauncher::launchProcess()::<lambda(GIOCondition)>, int, GIOCondition>::call(GIOCondition) (this=0x5951fa10, in#0=(G_IO_IN | G_IO_HUP)) at WTF/Headers/wtf/Function.h:53 (gdb) print this $1 = (WTF::Detail::CallableWrapper<WebKit::ProcessLauncher::launchProcess()::<lambda(GIOCondition)>, int, GIOCondition> * const) 0x5951fa10 (gdb) print m_callable $2 = {__protectedThis = {m_ptr = 0x3}, __this = 0x1, __pidSocket = {m_ptr = 0x59ef9890}}