WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
80495
[GTK] race condition in run-gtk-tests
https://bugs.webkit.org/show_bug.cgi?id=80495
Summary
[GTK] race condition in run-gtk-tests
Philippe Normand
Reported
2012-03-06 23:36:51 PST
Between at-spi-bus-launcher being slow at setting up the a11y bus and testatk trying to poke it too fast I think. One way to fix this is to make run-gtk-tests wait the bus have been started before launching the tests.
Attachments
Patch
(6.21 KB, patch)
2012-03-07 00:34 PST
,
Philippe Normand
no flags
Details
Formatted Diff
Diff
Patch
(6.92 KB, patch)
2012-03-07 01:37 PST
,
Philippe Normand
mrobinson
: review-
Details
Formatted Diff
Diff
Patch
(7.30 KB, patch)
2012-03-07 08:14 PST
,
Philippe Normand
mrobinson
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Philippe Normand
Comment 1
2012-03-06 23:37:36 PST
Also, when testatk fails to connect, it blocks the whole thing for 20 minutes...
Martin Robinson
Comment 2
2012-03-06 23:59:31 PST
Nice catch. We definitely need to fix this, for the sake of the bots!
Philippe Normand
Comment 3
2012-03-07 00:06:20 PST
I started a patch, making the script run a glib main loop and connecting to the bus's NameOwnerChanged to wait on the a11y bus. I'll rewrite it using gdbus instead of python-dbus.
Philippe Normand
Comment 4
2012-03-07 00:34:17 PST
Created
attachment 130558
[details]
Patch
Philippe Normand
Comment 5
2012-03-07 01:37:16 PST
Created
attachment 130569
[details]
Patch
Martin Robinson
Comment 6
2012-03-07 06:55:13 PST
Comment on
attachment 130569
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=130569&action=review
Nice work, though I think this could use a little cleanup.
> Tools/Scripts/run-gtk-tests:22 > +import os, sys, time
Each import should have its own line.
> Tools/Scripts/run-gtk-tests:24 > + > +from gi.repository import Gio, GLib
No newline necessary here.
> Tools/Scripts/run-gtk-tests:88 > + def _wait_dbus_service_and_run(self, service_name, handler):
_run_command_when_dbus_service_appears? How are timeouts handled here?
> Tools/Scripts/run-gtk-tests:113 > + global timed_out;
Instead of a global variable, why not an instance variable?
> Tools/Scripts/run-gtk-tests:131 > + def check_bailout():
You should probably rename this to something like: "check_if_tests_have_timed_out"
> Tools/Scripts/run-gtk-tests:138 > + r = False > + if now - start > TIMEOUT: > + sys.stdout.write("Tests timed out after %d seconds\n" % TIMEOUT) > + sys.stdout.flush() > + r = True > + return r
You can just use an early return here and avoid the variable: if now.time() - start <= TIMEOUT: return True sys.stdout.write("Tests timed out after %d seconds\n" % TIMEOUT) sys.stdout.flush() return False
> Tools/Scripts/run-gtk-tests:152 > + # Make sure the accessibility registry daemon is running. > + a11y_registryd_running = False > + a11y_registryd_path = self._lookup_atspi2_binary(jhbuild_path, 'at-spi2-registryd') > + if a11y_registryd_path: > + try: > + a11y_registryd = Executive().popen([a11y_registryd_path], env=test_env) > + a11y_registryd_running = True > + except: > + sys.stderr.write("Failed to run the accessibility registry\n") > + sys.stderr.flush() > +
This could probably be a helper. You could avoid the comment that way: def _ensure_accessibility_daemon_is_running(self):
> Tools/Scripts/run-gtk-tests:161 > + if check_bailout(): > + timed_out = True > + break
This doesn't seem to work in situations where the test never halts, right?
Philippe Normand
Comment 7
2012-03-07 07:59:58 PST
(In reply to
comment #6
)
> > > Tools/Scripts/run-gtk-tests:88 > > + def _wait_dbus_service_and_run(self, service_name, handler): > > _run_command_when_dbus_service_appears? > > How are timeouts handled here? >
Hum I don't see what could time out here. Can you elaborate please?
> > > Tools/Scripts/run-gtk-tests:161 > > + if check_bailout(): > > + timed_out = True > > + break > > This doesn't seem to work in situations where the test never halts, right?
True :( I wish gtester had some way to handle tests timing out.
Philippe Normand
Comment 8
2012-03-07 08:14:30 PST
Created
attachment 130627
[details]
Patch
Martin Robinson
Comment 9
2012-03-07 08:42:30 PST
Comment on
attachment 130627
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=130627&action=review
Looks good, but consider converting the a11y stuff to use with. Perhaps this could be a follwoup patch.
> Tools/Scripts/run-gtk-tests:149 > + def run_for_real():
Maybe run_for_real could be called run_tests. :)
> Tools/Scripts/run-gtk-tests:164 > + if self._a11y_registryd: > + self._a11y_registryd.terminate() > + > + a11y_bus_launcher.terminate()
It seems we want to be really sure that the a11y stuff is cleaned up properly when exiting the loop, so I think it makes sense to use "with" here.
http://docs.python.org/release/2.5/whatsnew/pep-343.html
Without using this, we run the risk of an exception preventing the termination of the a11y stuff. I think I've seen this happen to me.
Philippe Normand
Comment 10
2012-03-07 08:58:49 PST
Committed
r110059
: <
http://trac.webkit.org/changeset/110059
>
Philippe Normand
Comment 11
2012-03-07 09:01:30 PST
(In reply to
comment #9
)
> (From update of
attachment 130627
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=130627&action=review
> > Looks good, but consider converting the a11y stuff to use with. Perhaps this could be a follwoup patch. >
I'll try this in a follow-up patch, thanks!
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug