Bug 121294

Summary: [GTK] socket_embed_hook hitting NULL-check assertion running TestWebKit2
Product: WebKit Reporter: Mario Sanchez Prada <mario>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: apinheiro, cgarcia, commit-queue, gustavo, mrobinson, zan
Priority: P2 Keywords: Gtk
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch proposal
none
Patch proposal none

Description Mario Sanchez Prada 2013-09-13 05:07:46 PDT
Many CRITICAL errors like the following can be seen now in the GTK bots when running the TestWebKitAPI/TestWebKit2 test suite (see [1]):

   [...]

   [==========] Running 51 tests from 3 test cases.
   [----------] Global test environment set-up.
   [----------] 38 tests from WebKit2
   [ RUN      ] WebKit2.AboutBlankLoad

   ** (TestWebKit2:29498): CRITICAL **: socket_embed_hook: assertion `spi_global_register != NULL' failed
   [       OK ] WebKit2.AboutBlankLoad (171 ms)
   [ RUN      ] WebKit2.CloseThenTerminate

   ** (TestWebKit2:29498): CRITICAL **: socket_embed_hook: assertion `spi_global_register != NULL' failed
   [       OK ] WebKit2.CloseThenTerminate (172 ms)
   [ RUN      ] WebKit2.CookieManager

   ** (TestWebKit2:29498): CRITICAL **: socket_embed_hook: assertion `spi_global_register != NULL' failed
   [       OK ] WebKit2.CookieManager (154 ms)
   [ RUN      ] WebKit2.DidNotHandleKeyDown

   [...]

The problem seems to be that the ATK bridge is being properly initialized for the first time that gtk_main() is being called (i.e. for the first test), but then shutdown after that point and never initialized again. Thus, this seems to be a GTK+ bug to me, but still we need to find a way to deal with it here in WebKit IMHO.


[1] http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release/builds/40662/steps/API%20tests/logs/stdio
Comment 1 Mario Sanchez Prada 2013-09-13 05:26:02 PDT
I just filed the appropriate bug in GTK+ and attached a patch to it:
https://bugzilla.gnome.org/show_bug.cgi?id=708024

I will provide a similar solution (which I already tested and works) for WebKitGTK+'s jhbuild environment (as a patch for gtk 3.6), so we can bring some sanity to our bots as well in the meanwhile.
Comment 2 Mario Sanchez Prada 2013-09-13 05:32:57 PDT
Created attachment 211545 [details]
Patch proposal

Here comes the patch that seems to fix the issue for our version of GTK+.

I'm not setting the r? flag yet since I'd rather wait for the patch to be applied first in upstream GTK+

Once that happens, I'll come back here and set the flag if it gets accepted.
Comment 3 Mario Sanchez Prada 2013-09-16 02:06:29 PDT
Adding Zan to CC, just to keep him on the loop (I guess he might be interested)
Comment 4 Mario Sanchez Prada 2013-09-16 09:48:48 PDT
Created attachment 211804 [details]
Patch proposal

After some discussion on #a11y with other GTK+/GAIL developers (Alejandro Pinheiro, Benjamin Otte), we seem to agree the right thing to do is to remove the call to _gtk_accessibility_shutdown() completely, since it made sense in the times of the atk-bridge being loaded as a module, but it does not anymore. Check the full IRC log in [1], which has been finally been marked as duplicate of [2] where a final patch has been proposed and accepted (to commit only after the freeze).

Hence, I'm proposing now a similar patch here to cope with the issue in WebKitGTK's internal jhbuild in the meanwhile. Please review.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=708024
[2] https://bugzilla.gnome.org/show_bug.cgi?id=684076
Comment 5 Mario Sanchez Prada 2013-09-20 03:20:41 PDT
(In reply to comment #4)
> Created an attachment (id=211804) [details]
> Patch proposal
> 
> After some discussion on #a11y with other GTK+/GAIL developers (Alejandro Pinheiro, Benjamin Otte), we seem to agree the right thing to do is to remove the call to _gtk_accessibility_shutdown() completely, since it made sense in the times of the atk-bridge being loaded as a module, but it does not anymore. Check the full IRC log in [1], which has been finally been marked as duplicate of [2] where a final patch has been proposed and accepted (to commit only after the freeze).
> 
> Hence, I'm proposing now a similar patch here to cope with the issue in WebKitGTK's internal jhbuild in the meanwhile. Please review.
> 
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=708024
> [2] https://bugzilla.gnome.org/show_bug.cgi?id=684076

Ping reviewers?

I think this is quite straightforward fix (even if it's temporary while not in GTK 3.12), and would help get rid of those crazy CRITICALs in the bots.

It will not take much time. Promised :)
Comment 6 Mario Sanchez Prada 2013-09-20 08:23:44 PDT
Comment on attachment 211804 [details]
Patch proposal

Thanks for the review, Martin
Comment 7 WebKit Commit Bot 2013-09-20 08:46:18 PDT
Comment on attachment 211804 [details]
Patch proposal

Clearing flags on attachment: 211804

Committed r156167: <http://trac.webkit.org/changeset/156167>
Comment 8 WebKit Commit Bot 2013-09-20 08:46:21 PDT
All reviewed patches have been landed.  Closing bug.