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)
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
Reporter | ||
Comment 1•13 years ago
|
||
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
Reporter | ||
Comment 2•13 years ago
|
||
(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.
Reporter | ||
Comment 3•13 years ago
|
||
(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.
Description
•