On Wed, Dec 09, 2020 at 10:46:52PM -0000, Rico Tzschichholz wrote:
> This issue is not restricted to arm* but have been seen occasionally on amd64.
> It effects the binary package build too, where these tests are part of "make check".
>
> There are a lot tests disabled in
> 'sw/qa/uitest/writer_dialogs/openDialogs.py' for similar reasons.
>
> So while it locks up at "test_21_.uno:EditGlossary (openDialogs.openDialogs) ... " I would give that a try:
> https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?id=0136e1c7a8f8823cbd0e5027ed203ee0d2f71262
Thanks for the bug reference - I had an unconfirmed theory that the test
was deadlocking somewhere!
I think Heather mentioned seeing this in other tests too - it would be
good to grep the failing logs to see... seems like the string when it
starts a test doesn't contain a \n, so it looks like:
test_21_.uno:EditGlossary (openDialogs.openDialogs) ... autopkgtest [22:36:52]: ERROR: timed out on command "...
If it's only this one, or only a small number of tests which can hang
(on slow / loaded machines particularly it seems) always, then skipping
those few would be a reasonable solution, indeed.
But if this can apply to any of the uicheck tests, then I think I'm
still in favour of using timeout(1) to paper over the deadlock, by
setting our own timeout, lower than the autopkgtest one, and skipping if
we hit it.
On Wed, Dec 09, 2020 at 10:46:52PM -0000, Rico Tzschichholz wrote: uitest/ writer_ dialogs/ openDialogs. py' for similar reasons. .uno:EditGlossa ry (openDialogs. openDialogs) ... " I would give that a try: /git.launchpad. net/~libreoffic e/ubuntu/ +source/ libreoffice/ commit/ ?id=0136e1c7a8f 8823cbd0e5027ed 203ee0d2f71262
> This issue is not restricted to arm* but have been seen occasionally on amd64.
> It effects the binary package build too, where these tests are part of "make check".
>
> There are a lot tests disabled in
> 'sw/qa/
>
> So while it locks up at "test_21_
> https:/
Thanks for the bug reference - I had an unconfirmed theory that the test
was deadlocking somewhere!
I think Heather mentioned seeing this in other tests too - it would be
good to grep the failing logs to see... seems like the string when it
starts a test doesn't contain a \n, so it looks like:
test_ 21_.uno: EditGlossary (openDialogs. openDialogs) ... autopkgtest [22:36:52]: ERROR: timed out on command "...
If it's only this one, or only a small number of tests which can hang
(on slow / loaded machines particularly it seems) always, then skipping
those few would be a reasonable solution, indeed.
But if this can apply to any of the uicheck tests, then I think I'm
still in favour of using timeout(1) to paper over the deadlock, by
setting our own timeout, lower than the autopkgtest one, and skipping if
we hit it.
Cheers,
--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]