All tests that are stucked, implements closing a request via a timeout (and then, executing "run"). The bet is that the timeout is short enough (1s) so that, when autopkgtests infra is busy, time to execute the bash subcommand is taking more than a second, and so "dismissing" is ran before execution happens and the whole testsuite hangs.
There are few instances of setting this timeout function:
$ grep eout_add_sec test/*
test/test_ui_gtk.py: GLib.timeout_add_seconds(1, cont)
test/test_ui_gtk.py: GLib.timeout_add_seconds(1, cont)
test/test_ui_gtk.py: GLib.timeout_add_seconds(1, cont)
test/test_ui_gtk.py: GLib.timeout_add_seconds(1, c)
test/test_ui_gtk.py: GLib.timeout_add_seconds(1, c)
Short term solution could be to increase the timeout. Long term would be to eliminate this potential race implementing cancelling differently.
The autopkgtests are sometimes passing, sometimes stuck for more than 2h: autopkgtest. ubuntu. com/packages/ apport/ cosmic/ amd64.
http://
It's blocking randomly on different tests.
All tests that are stucked, implements closing a request via a timeout (and then, executing "run"). The bet is that the timeout is short enough (1s) so that, when autopkgtests infra is busy, time to execute the bash subcommand is taking more than a second, and so "dismissing" is ran before execution happens and the whole testsuite hangs.
There are few instances of setting this timeout function: ui_gtk. py: GLib.timeout_ add_seconds( 1, cont) ui_gtk. py: GLib.timeout_ add_seconds( 1, cont) ui_gtk. py: GLib.timeout_ add_seconds( 1, cont) ui_gtk. py: GLib.timeout_ add_seconds( 1, c) ui_gtk. py: GLib.timeout_ add_seconds( 1, c)
$ grep eout_add_sec test/*
test/test_
test/test_
test/test_
test/test_
test/test_
Short term solution could be to increase the timeout. Long term would be to eliminate this potential race implementing cancelling differently.