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
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.
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.
Adding Zan to CC, just to keep him on the loop (I guess he might be interested)
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
(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 on attachment 211804 [details] Patch proposal Thanks for the review, Martin
Comment on attachment 211804 [details] Patch proposal Clearing flags on attachment: 211804 Committed r156167: <http://trac.webkit.org/changeset/156167>
All reviewed patches have been landed. Closing bug.