[Webkit-unassigned] [Bug 281666] New: [GTK] [2.46.1] Crash on i386 when running the ruby-gnome test

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=281666

            Bug ID: 281666
           Summary: [GTK] [2.46.1] Crash on i386 when running the
                    ruby-gnome test
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: berto at igalia.com
                CC: bugs-noreply at webkitgtk.org

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 at entry=4151103232, signo=signo at entry=6, no_tid=no_tid at 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 at 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 at entry=1, dispatch=dispatch at 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}}

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20241017/15d76b31/attachment-0001.htm>