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

timeout option giving up? #95

Closed
Eh2406 opened this issue Sep 23, 2018 · 8 comments
Closed

timeout option giving up? #95

Eh2406 opened this issue Sep 23, 2018 · 8 comments
Labels
bug This is a bug

Comments

@Eh2406
Copy link

Eh2406 commented Sep 23, 2018

While trying to debug why rust-lang/cargo#5921 is timing out on CI, I tried adding a value for the timeout option. When I try it locally after running for 20 minutes, I get Test aborted: Giving up after 10000 child processes crashed with no other info on how to proceed. I know it is rued of me not to have a MCVE, but I don't know how to did in. How should I start debugging this?

@AltSysrq
Copy link
Collaborator

Whoops, there's code to generate error messages but nothing to actually print them except for the final test failure.

I'm planning to do a new release tomorrow, so I'll see about adding a "verbose" option or similar.

@Eh2406
Copy link
Author

Eh2406 commented Sep 23, 2018

Thank you! I look forward to the new release!

Also can we reduce the number of tries to like 100 or 1000? 20 min was a long time to discover it was not doing anything.

@AltSysrq
Copy link
Collaborator

Hm, to get 10000 processes crashed in 20 minutes, you'd need an average process lifetime of 120ms, so if you didn't set a timeout below that, I'd expect some output from aborting anyway, unless you're getting segfaults or something.

Also can we reduce the number of tries to like 100 or 1000?

Yeah, this ties into something I was planning for #91, to allow capping the number of iterations in the shrinking process.

In the mean time, I'd suggest putting .no_shrink() on your top-level strategy so you can get at least some information.

@Eh2406
Copy link
Author

Eh2406 commented Sep 23, 2018

It is possible that in flailing around trying to figure out what was going on I tried a very short time out. If that did not give enough time for the process to startup that would explain the problem. Maybe a warning about two short a timeout should go in the docs?

I was already using .no_shrink(), I am glad to here I was on the rite track.

@AltSysrq
Copy link
Collaborator

that did not give enough time for the process to startup

Ouch, I hadn't thought of that edge case before. I'll at least add a warning, but it may be possible to catch that happening directly.

@Eh2406
Copy link
Author

Eh2406 commented Sep 23, 2018

Thanks for all the help! I am trying a longer timeout (3000) and we will see what the runtime is and output looks like. I am hopeful that it won't Giving up with a more reasonable number.

@AltSysrq
Copy link
Collaborator

AltSysrq commented Sep 23, 2018

0.8.7 has a few things that should help here.

  • Config::verbose (or PROPTEST_VERBOSE) can be set to make proptest log what failures occur as they happen.

  • See A no shrink setting. #91 for some added configuration options to control shrinking.

  • There's now code to detect if the child process crashes or terminates before starting any tests so it doesn't go into a near infinite loop of spawning child processes.

@Eh2406
Copy link
Author

Eh2406 commented Sep 24, 2018

Thanks!

Clear error message. ✔️ Better diagnostic tools. ✔️ Timeout working correctly. ✔️

One thing I did notes thow is that the verbose is only "real time" if the test is run with --nocapture. Which may be worth mentioning in the docs.

@Eh2406 Eh2406 closed this as completed Oct 21, 2018
@AltSysrq AltSysrq added the bug This is a bug label Dec 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This is a bug
Projects
None yet
Development

No branches or pull requests

2 participants