Skip to content
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

Merged
merged 2 commits into from
Mar 9, 2016
Merged

Conversation

MartinNowak
Copy link
Member

  • 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

See also dlang/druntime#1503

@braddr
Copy link
Member

braddr commented Mar 7, 2016

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
@braddr
Copy link
Member

braddr commented Mar 8, 2016

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.

@MartinNowak
Copy link
Member Author

I disable QUIET by default, let's see whether that works.

@braddr
Copy link
Member

braddr commented Mar 8, 2016

Auto-merge toggled on

braddr added a commit that referenced this pull request Mar 9, 2016
 use timelimit to kill deadlocked tests
@braddr braddr merged commit c15d43c into dlang:master Mar 9, 2016
@MartinNowak MartinNowak deleted the timelimit branch March 9, 2016 10:44
@schveiguy
Copy link
Member

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?

@MartinNowak
Copy link
Member Author

I think there is a problem here, see e.g. https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=1988453&isPull=true

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.

@schveiguy
Copy link
Member

I misread the details, I thought the cluster of tests completing indicated they were all running together.

@schveiguy
Copy link
Member

Another one, also on free_list.run.
https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=1996466&isPull=true

Might this be something to do with the test? I haven't looked at it in detail.

@MartinNowak
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants