[Webkit-unassigned] [Bug 161481] [GTK] Use GTestDBus instead of dbus-launch in WebKitTestBus.cpp

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Nov 2 00:16:23 PDT 2016


--- Comment #10 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #8)
> Comment on attachment 293416 [details]
> Patch
> The problem is that if you do that, the test will randomly crash; we don't
> need more flaky tests.

Why? Could you show a bt of one of such crashes? Because our current code is calling setenv in the same place, this patch is only replacing the code that GTestDBus with GTestDBus.

> In fact, since g_test_dbus_up() calls setenv()
> itself, it suffers from the same problem.

Exactly, it's not a problem of this patch, but an existing problem (if any) and I have never seen random crashes in the tests using WebKitTestBus.

> We need to be careful to only call
> such functions (a) at the very top of main(),

Which is exactly what happens. This is not public API, this is an internal helper class designed to be used by tests that should do this at the very beginning of beforeAll():

bus = new WebKitTestBus();
if (!bus->run())

And beforeAll() is called by main() right after setting up the environment and registering gresources. There isn't any other code before that, nor any other secondary thread created.

> or (b) when we're really
> really sure that it's before the first secondary thread has been created,
> otherwise the test will be flaky. And it's impossible for WebKitTestBus to
> guarantee where it's used from, so it really needs to not be setting
> environment variables.

We are already ensuring both a) and b), and we don't need WebKitTestBus to ensure anything, we just need to use it as it's designed to be used, at the very beginning of beforeAll(). Another option would be to do it unconditionally in main() for all tests, but that could slow down the tests that don't need dbus at all.

> Is it even possible to create a GObject without starting secondary threads?

There isn't any thread nor GObject created in this case when WebKitTestBus::run is called.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161102/db546a94/attachment.html>

More information about the webkit-unassigned mailing list