710577 - runtests.py stuck in livelock when .as needs to be compiled to an .abc

Status: RESOLVED WORKSFORME

(Tamarin Graveyard :: Tools, defect)

Description

[Felix S. Klock II [:pnkfelix, :fklock]]

I am trying to run the acceptance tests without providing a --timeout argument.  If the .abc's already exist, they run fine, but if an .abc is missing, runtests not only fails to compile the file, it also gets stuck in its while True loop in runTests

If you run with --timeout, the issue is hidden because it will break out of the while True loop when the threshold has been crossed.

Command line (but AFAICT this is not really relevant, apart from pointing out that --timeout is not on the command line):

% python runtests.py -v -d --avm ../../objdir-rel64/shell/avmshell as3/Definitions/FunctionAccessors/AccessorSpraySmall.as

Comment 1

[Felix S. Klock II [:pnkfelix, :fklock]]

Problem is that BUILTINABC was not set.  I could not tell that was the problem because the issue is only signaled via an argument to the exit() method.

There's a big problem in runtests.py where it uses exit when encountering errors like this instead of throwing exceptions and/or emitting debug messages.  :(

Comment 2

[Felix S. Klock II [:pnkfelix, :fklock]]

(In reply to Felix S Klock II from comment #1)
> Problem is that BUILTINABC was not set.  I could not tell that was the
> problem because the issue is only signaled via an argument to the exit()
> method.

In case its not clear from the above: it appears that calls to exit do not cause an exit, at least not when one is running within a threadpool.

Comment 3

[Felix S. Klock II [:pnkfelix, :fklock]]

(In reply to Felix S Klock II from comment #1)
> Problem is that BUILTINABC was not set.  I could not tell that was the
> problem because the issue is only signaled via an argument to the exit()
> method.
> 
> There's a big problem in runtests.py where it uses exit when encountering
> errors like this instead of throwing exceptions and/or emitting debug
> messages.  :(

Throwing an exception does not seem to fix the issue.  It *seems* like the exception thrown from a worker is silently discarded.  I do not undertand this since it seems to me (from looking at what I believe to be the API for the threadpool library) that we should be catching the exception via an exception handling callback.

My current hypothesis is that we are not hooking up our callback properly.