<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Use GTestDBus instead of dbus-launch in WebKitTestBus.cpp"
href="https://bugs.webkit.org/show_bug.cgi?id=161481#c13">Comment # 13</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Use GTestDBus instead of dbus-launch in WebKitTestBus.cpp"
href="https://bugs.webkit.org/show_bug.cgi?id=161481">bug 161481</a>
from <span class="vcard"><a class="email" href="mailto:cgarcia@igalia.com" title="Carlos Garcia Campos <cgarcia@igalia.com>"> <span class="fn">Carlos Garcia Campos</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=161481#c12">comment #12</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=161481#c10">comment #10</a>)
> > 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.
>
> Here's one example of such a crash, with a backtrace:
>
> <a href="https://bugzilla.gnome.org/show_bug.cgi?id=754951">https://bugzilla.gnome.org/show_bug.cgi?id=754951</a>
>
> We had a second case in some important GNOME component recently, but I
> honestly don't remember where and can't find it now. And we have third one
> in Endless's private bug tracker right now.</span >
I don't care about other applications crashing, this bug is about our unit tests, we have done this forever and I've never seen a crash, so I don't understand why you say that this patch is going to be the source of crashes and flaky tests.
<span class="quote">> > > 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())
> > return;
> >
> > 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.
>
> OK, then it should be OK, but it is so easy to misuse that I would prefer
> that you add an assertion to guarantee this. Unfortunately the best example
> I found requires reading /proc:
>
> <a href="http://stackoverflow.com/a/13993822/1120203">http://stackoverflow.com/a/13993822/1120203</a>
>
> but it could be done inside #ifndef NDEBUG. Then if that check passes, we
> can be confident that GLib isn't creating any secondary thread somewhere
> before the setenv.</span >
This is private API for unit tests, I don't think we need to complicate things to fix a problem that doesn't exist.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>