-
-
Notifications
You must be signed in to change notification settings - Fork 725
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
use timelimit to kill deadlocked tests #4059
Conversation
Same issue as the druntime pull, not working on linux. Also, due to the default value of QUIET, can't be sure it's actually being used just from the logs. |
- restrict any test to 60s - don't trigger the 1h timeout for the auto-tester - get a make error message w/ a specific test on timeout failure - the timelimit program is used b/c the auto-tester already relies on it
Presumably the change is working, since the errors about not finding 'command' went away, but I think it'd be good to go ahead and change the default value of QUIET in this change so there's solid proof, and to match what's been done elsewhere. |
I disable QUIET by default, let's see whether that works. |
Auto-merge toggled on |
use timelimit to kill deadlocked tests
I think there is a problem here, see e.g. https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=1988453&isPull=true What I think is happens is that because we fork 8 threads to run the tests, many of them can run in parallel. If too many of the time consuming tests are running at the same time, they can reach this time limit. Perhaps the time limit can be set to 8 * 60? |
I don't think that std/experimental/allocator/building_blocks/free_list.run would ever take 1 minute to complete (it's usually 6ms). And it shouldn't starve b/c all the other tests already completed. |
I misread the details, I thought the cluster of tests completing indicated they were all running together. |
Another one, also on free_list.run. Might this be something to do with the test? I haven't looked at it in detail. |
Most likely some busy loop or dead-lock in the SharedFreeList test. Might as well be an extreme contention w/ the 20 threads, but taking longer than 1 second instead of the usual 10 ms seems unlikely. |
See also dlang/druntime#1503