runtime: add test for syscall failing to create new OS thread during syscall.Exec #20822
Comments
/cc @ianlancetaylor since i referenced his comment |
I'm not surprised that this fails, and I don't think it's a bug. Running If you want to show a real problem, run |
This while loop is running |
Also worth noting this is reproducible after few runs (10 or 20 runs). It is not consuming all the pids on the system |
Ah, OK, sorry. What does Immediately after the loop fails, what does |
it is really hard to make the loop fail, but i currently have 377 threads running. I don't imagine this loop to be adding enough processed and/or threads to exceed the limit:
|
Here's the system wide limits:
I really doubt this has anything to do with limits |
Any difference with Go 1.9beta2? |
Ah, you're right. This is #18146 for a program that doesn't use cgo. Sorry for forgetting about that. |
Good to hear. So I guess what this bug needs now is a test. I think we'd prefer you use go1.9beta2 as your fix rather than GOMAXPROCS=1 as a workaround. Go 1.9 has no known bugs compared to Go 1.8. |
@bradfitz do you think converting the bash loop into a go test will be ok to merge in ? I'm concerned that this might be flaky test. what do you think ? |
Ideally the test should execute pretty quickly. And flaky tests are no good, but I don't see why this one would be flaky. Rather than expect a failure in, say, 10,000 iterations, just do 10,000 iterations and pass if you don't get a failure. Assuming you used to generally get a failure in 10,000 iterations. |
Hello @jvshahid, might you be interested or available to submit a CL with the suggested test for Go1.11? |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.8 linux/amd64
(same behavior with 1.8.3)What operating system and processor architecture are you using (
go env
)?What did you do?
Run this app in a while loop, e.g.
while true; do go run main.go; done
What did you expect to see?
What did you see instead?
Kernel version (uname -a)
There are few issues that were opened in the past with the same error message. The most relevant comment i found in all of them is this comment which suggests that this could be a kernel issue and was looking for a way to reproduce the problem. Some interesting notes:
GOMAXPROCS
to1
make the problem hard to reproduce (may be event eliminate it)The text was updated successfully, but these errors were encountered: