This is happening with webkitgtk+ 2.0.3, libwebkitgtk-3.0.so (so GTK+ 3 and not WebKit2) I have an application that in certain situations creates a webview only to destroy it later (because a condition is met and we can't use it). This seems to trigger a race and later on the application crashes: Program received signal SIGSEGV, Segmentation fault. WebKit::core (webView=0x3fb999999999999a) at ../Source/WebKit/gtk/webkit/webkitwebview.cpp:5415 5415 ../Source/WebKit/gtk/webkit/webkitwebview.cpp: No such file or directory. (gdb) bt #0 WebKit::core (webView=0x3fb999999999999a) at ../Source/WebKit/gtk/webkit/webkitwebview.cpp:5415 #1 0x00007ffff51798b8 in WebKit::GtkAdjustmentWatcher::updateAdjustmentsFromScrollbars (this=0x20f6540) at ../Source/WebKit/gtk/WebCoreSupport/GtkAdjustmentWatcher.cpp:65 #2 0x00007ffff5179939 in WebKit::updateAdjustmentCallback ( watcher=<error reading variable: value has been optimized out>) at ../Source/WebKit/gtk/WebCoreSupport/GtkAdjustmentWatcher.cpp:76 #3 0x00007fffeff30fa3 in g_timeout_dispatch (source=source@entry=0x21015b0, callback=<optimized out>, user_data=<optimized out>) at gmain.c:4413 #4 0x00007fffeff30446 in g_main_dispatch (context=0x65f500) at gmain.c:3054 #5 g_main_context_dispatch (context=context@entry=0x65f500) at gmain.c:3630 #6 0x00007fffeff30798 in g_main_context_iterate (context=context@entry=0x65f500, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3701 #7 0x00007fffeff3083c in g_main_context_iteration (context=0x65f500, context@entry=0x0, may_block=may_block@entry=1) at gmain.c:3762 #8 0x00007ffff1096624 in g_application_run (application=0x68c110, argc=argc@entry=1, argv=argv@entry=0x7fffffffdf58) at gapplication.c:1623 #9 0x0000000000409e76 in main (argc=1, argv=0x7fffffffdf58) at main.c:78 (gdb) This only happens about 10-20% of the time with one webview being created and quickly destroyed. I have found these bugs which look like are hitting the same issue in webkitgtk+ and happen in different applications (empathy, epiphany, eclipse): https://bugzilla.redhat.com/show_bug.cgi?id=928783 https://bugzilla.redhat.com/show_bug.cgi?id=869598 https://bugzilla.redhat.com/show_bug.cgi?id=874353
14:18 < kov> pochu, hmm, sounds like a bug indeed, you should probably make ChromeClientGtk's member be an OwnPtr<GtkAdjustmentWatcher> I'm not going to have time to work on this, in case somebody wants to pick it up.
Created attachment 207246 [details] fix
Thanks for the patch! Unfortunately, based on the context here, I'm not sure how this fixes the issue and it is missing a ChangeLog with a complete explanation. Please see https://www.webkit.org/coding/contributing.html for more information about the process of submitting fixes. With a bit of context, it will be easier for me to review the patch. The main issue I have at this point is that I do not know how switching the member to be allocated manually changes the semantics. It shouldn't as far as I can see.
I don't understand how the GtkAdjustmentWatcher can be alive after the web view is destroyed. And making it heap allocated shouldn't change anything, it will be deleted in the ChromeClient destructor.
To be honest I don't really speak C++, Gustavo suggested me to try this fix and it worked. Best to ask him directly if you have any question.
I've noticed something weird while looking at the GtkAdjustmentWatcher code. The idle source is not correctly reset in some cases, so I'm not sure but the patch attached to bug #119003 could fix this problem. I think something like this could have happened: 1.- WebView is created 2.- updateAdjustmentsFromScrollbarsLater is called from ChromeClient::contentsSizeChanged. This method also schedules a web view resize 3.- web view size allocate is called before the update scrollbar idle source is called (since resize has higher priority than idle sources) 4.- size allocate calls GtkAdjustmentWatcher::updateAdjustmentsFromScrollbars that resets the idle source without actually destroying the source (see bug #119003) 5.- web view is destroyed and GtkAdjustmentWatcher too. 6.- update adjustments idle source callback is called. 7.- crash! I guess it doesn't crash earlier because GtkAdjustmentWatcher is stack allocated so the pointer is still valid after it has been deleted. could someone try the patch in bug #119003 to see if the problem can be still reproduced?
(In reply to comment #6) > could someone try the patch in bug #119003 to see if the problem can be still reproduced? Indeed this patch seems to fix this bug as well. Feel free to close as a dup.
(In reply to comment #7) > (In reply to comment #6) > > could someone try the patch in bug #119003 to see if the problem can be still reproduced? > > Indeed this patch seems to fix this bug as well. Feel free to close as a dup. Great, thanks for confirming, I guess using GOwnPtr fixed the problem because when heap allocated the pointer is set to 0 when destroyed, but the real problem (fixed in bug #119003) was still there. *** This bug has been marked as a duplicate of bug 119003 ***
Err, I thought the adjustment watcher was already heap allocated and just not being deleted.