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

Unhelpful panic when unable to clone() a new thread #636

Closed
gopherbot opened this issue Mar 3, 2010 · 3 comments
Closed

Unhelpful panic when unable to clone() a new thread #636

gopherbot opened this issue Mar 3, 2010 · 3 comments

Comments

@gopherbot
Copy link
Contributor

by konrad.meyer:

> Before filing a bug, please check whether it has been fixed since
> the latest release: run "hg pull -u" and retry what you did to
> reproduce the problem.  Thanks.

Did this; problem still exists.

What steps will reproduce the problem?
1. Compile and run the attached go program (starts a bunch of goroutines
that try to open a bunch of TCP connections).
2.
3.

What is the expected output? What do you see instead?
There should be no output. Instead, I see the results in the attached .txt
file (somewhat truncated, but it's 11M unzipped).


What is your $GOOS?  $GOARCH?
Linux, amd64


Which revision are you using?  (hg identify)
88d305c3f261 tip


Please provide any additional information below.
Feel free to contact me if you need more information. I think the provided
.go source is a fairly minimal test (I *think* it only occurs from
goroutines, and only with a fairly large number of attempts to bogus,
non-localhost ports). I could be wrong, though.

Attachments:

  1. test.go (293 bytes)
  2. a.txt.gz (179450 bytes)
@gopherbot
Copy link
Contributor Author

Comment 1 by stephenm@golang.org:

This isn't a socket problem. Instead, when the go runtime is unable to create another
system thread using clone(), it panics in a rather unfriendly way. You get the same
result if you replace net.Dial() with syscall.Sleep(1e11). Note also that decreasing
the thread limit by somthing like "ulimit -u 500" will make the problem easier to
reproduce - you only need about 500 goroutines to cause the panic.

@gopherbot
Copy link
Contributor Author

Comment 2 by konrad.meyer:

Is this a duplicate of #549 then?

@gopherbot
Copy link
Contributor Author

Comment 3 by stephenm@golang.org:

yes, well spotted.

Status changed to Duplicate.

Merged into issue #549.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant