-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hang when pass failed to modify the variant shortly before STOP #156
Comments
For what it's worth, this particular bug in |
As for the hang problem itself, one easy fix would probably be to compare the files in |
Implement unit tests specifically for the TestManager class, with stubbing out the pass logic. Cover the basic successful minimization scenarios and basic error scenarios. This lays groundwork for the regression testing of marxin#156.
Implement unit tests specifically for the TestManager class, with stubbing out the pass logic. Cover the basic successful minimization scenarios and basic error scenarios. This lays groundwork for the regression testing of marxin#156.
Implement unit tests specifically for the TestManager class, with stubbing out the pass logic. Cover the basic successful minimization scenarios and basic error scenarios. This lays groundwork for the regression testing of marxin#156.
Close the file handle after it's not needed anymore. This problem was detected by pytest in my work for marxin#156: cvise/utils/misc.py:8: ResourceWarning: unclosed file <_io.TextIOWrapper name='input.txt' mode='r' encoding='UTF-8'> open(filename).read()
Make sure that we don't proceed with an unmodified file - for this, consistently validate the pass' results on both codepaths (in process_done_futures() and wait_for_first_success()). Besides fixing the hang that was possible when a pass misbehaved, there are a couple of other side effects: * more cases of ERRORs in a pass will be reported - previously only the ones on the first codepath were handled; * max_improvement is enforced stricter now - previously the second codepath allowed a larger reduction to sneak in. This fixes marxin#156.
Make sure that we don't proceed with an unmodified file - for this, consistently validate the pass' results on both codepaths (in process_done_futures() and wait_for_first_success()). Besides fixing the hang that was possible when a pass misbehaved, there are a couple of other side effects: * more cases of ERRORs in a pass will be reported - previously only the ones on the first codepath were handled; * max_improvement is enforced stricter now - previously the second codepath allowed a larger reduction to sneak in. This fixes marxin#156.
Make sure that we don't proceed with an unmodified file - for this, consistently validate the pass' results on both codepaths (in process_done_futures() and wait_for_first_success()). Besides fixing the hang that was possible when a pass misbehaved, there are a couple of other side effects: * more cases of ERRORs in a pass will be reported - previously only the ones on the first codepath were handled; * max_improvement is enforced stricter now - previously the second codepath allowed a larger reduction to sneak in. This fixes marxin#156.
I experience occasional hangs in particular passes, e.g.:
According to the initial investigation, there seems to be a bug in the
replace-dependent-typedef
pass, so that it sometimes reports success despite not making any changes in the file. This is normally caught by this check:cvise/cvise/utils/testing.py
Line 415 in 29fc072
, however this line is not reached if
quit_loop
has already been set toTrue
because an earlier invocation returnedPassResult.STOP
.The end effect is that the execution gets stuck in this state ~forever: the pass keeps being applied, the file remains the same all the time, and the file comparison check is skipped.
The text was updated successfully, but these errors were encountered: