Closed Bug 710577 Opened 13 years ago Closed 13 years ago

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

Categories

(Tamarin Graveyard :: Tools, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: pnkfelix, Unassigned)

Details

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
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. :(
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
(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.
(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.
You need to log in before you can comment on or make changes to this bug.