Bug 118396 – [GTK] crash on WebKit::GtkAdjustmentWatcher::updateAdjustmentsFromScrollbars when destroying a webview

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebKitGTK

[Emilio Pozuelo Monfort]

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

[Emilio Pozuelo Monfort]

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.

[Guillaume Desmottes]

Created attachment 207246 [details]
fix

[Martin Robinson]

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.

[Carlos Garcia Campos]

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.

[Guillaume Desmottes]

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.

[Carlos Garcia Campos]

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?

[Guillaume Desmottes]

(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.

[Carlos Garcia Campos]

(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 ***

[Gustavo Noronha (kov)]

Err, I thought the adjustment watcher was already heap allocated and just not being deleted.