Bug 60158 – [GTK] fast/dom/Geolocation/argument-types.html flaky crash on 32-bits Debug

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Philippe Normand]

First failing build http://build.webkit.org/builders/GTK%20Linux%2032-bit%20Debug/builds/15158

#0  0x0805cd41 in LayoutTestController::setGeolocationPermissionCommon (this=0x0, allow=true) at ../../Tools/DumpRenderTree/LayoutTestController.cpp:2401
2401	    m_isGeolocationPermissionSet = true;

Thread 1 (Thread 19495):
#0  0x0805cd41 in LayoutTestController::setGeolocationPermissionCommon (this=0x0, allow=true) at ../../Tools/DumpRenderTree/LayoutTestController.cpp:2401
#1  0x0806bd39 in LayoutTestController::setGeolocationPermission (this=0x0, allow=true) at ../../Tools/DumpRenderTree/gtk/LayoutTestControllerGtk.cpp:493
#2  0x08059c52 in setGeolocationPermissionCallback (context=0x5ae6d040, function=0x5b4b97b0, thisObject=0x5b4b97b0, argumentCount=1, arguments=0xffd41a30, exception=0xffd41a7c) at ../../Tools/DumpRenderTree/LayoutTestController.cpp:1314
#3  0x55771a37 in JSC::JSCallbackFunction::call (exec=0x5ae6d040) at ../../Source/JavaScriptCore/API/JSCallbackFunction.cpp:67
#4  0x557f9b22 in JSC::Interpreter::executeCall (this=0x8449888, callFrame=0x5b48479c, function=0x5b4b97b0, callType=JSC::CallTypeHost, callData=..., thisValue=..., args=...) at ../../Source/JavaScriptCore/interpreter/Interpreter.cpp:866
#5  0x558913ff in JSC::call (exec=0x5b48479c, functionObject=..., callType=JSC::CallTypeHost, callData=..., thisValue=..., args=...) at ../../Source/JavaScriptCore/runtime/CallData.cpp:38
#6  0x55f59f72 in WebCore::JSMainThreadExecState::call (exec=0x5b48479c, functionObject=..., callType=JSC::CallTypeHost, callData=..., thisValue=..., args=...) at ../../Source/WebCore/bindings/js/JSMainThreadExecState.h:48
#7  0x55f59972 in WebCore::JSCallbackData::invokeCallback (this=0x8a09278, args=..., raisedException=0x0) at ../../Source/WebCore/bindings/js/JSCallbackData.cpp:71
#8  0x55f62536 in WebCore::JSCustomPositionErrorCallback::handleEvent (this=0x8a09250, positionError=0x8a184d8) at ../../Source/WebCore/bindings/js/JSCustomPositionErrorCallback.cpp:58
#9  0x56508502 in WebCore::Geolocation::GeoNotifier::timerFired (this=0x8a08eb8) at ../../Source/WebCore/page/Geolocation.cpp:147
#10 0x565126d4 in WebCore::Timer<WebCore::Geolocation::GeoNotifier>::fired (this=0x8a08ee4) at ../../Source/WebCore/platform/Timer.h:100
#11 0x565f6707 in WebCore::ThreadTimers::sharedTimerFiredInternal (this=0x8118098) at ../../Source/WebCore/platform/ThreadTimers.cpp:112
#12 0x565f6651 in WebCore::ThreadTimers::sharedTimerFired () at ../../Source/WebCore/platform/ThreadTimers.cpp:90
#13 0x56967889 in WebCore::timeout_cb () at ../../Source/WebCore/platform/gtk/SharedTimerGtk.cpp:49
#14 0x588a216c in g_timeout_dispatch (source=0x89d1a70, callback=0, user_data=0x0) at /build/buildd-glib2.0_2.27.91-1-i386-BodI3i/glib2.0-2.27.91/./glib/gmain.c:3877
#15 0x588a17a5 in g_main_dispatch (context=0x80b1850) at /build/buildd-glib2.0_2.27.91-1-i386-BodI3i/glib2.0-2.27.91/./glib/gmain.c:2440
#16 g_main_context_dispatch (context=0x80b1850) at /build/buildd-glib2.0_2.27.91-1-i386-BodI3i/glib2.0-2.27.91/./glib/gmain.c:3013
#17 0x588a5d58 in g_main_context_iterate (context=0x80b1850, block=<value optimized out>, dispatch=1, self=0x8087130) at /build/buildd-glib2.0_2.27.91-1-i386-BodI3i/glib2.0-2.27.91/./glib/gmain.c:3091
#18 0x588a6297 in g_main_loop_run (loop=0x89ae420) at /build/buildd-glib2.0_2.27.91-1-i386-BodI3i/glib2.0-2.27.91/./glib/gmain.c:3299
#19 0x582c8dc9 in IA__gtk_main () at /build/buildd-gtk+2.0_2.20.1-1-i386-Ixfflh/gtk+2.0-2.20.1/gtk/gtkmain.c:1219
#20 0x08065bbf in runTest (testPathOrURL=...) at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:703
#21 0x0806529e in runTestingServerLoop () at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:495
#22 0x08067342 in main (argc=2, argv=0xffd429b4) at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:1180

setGeolocationPermissionCommon is called with a null LayoutTestController...

[Philippe Normand]

Seems like the fix for bug 40012 introduced this issue. Without http://trac.webkit.org/changeset/83562 I get no crash and with trunk I locally get a crash out of 500 iterations of the test.

[Martin Robinson]

CCing the people involved with this bug. Do either of you know what might be causing this crash?

[Zan Dobersek]

This test was consistently passing on all the builders so its expectations were removed in r116553[1].

Closing the bug.

1: http://trac.webkit.org/changeset/116553