runtime/cgo: pthread_create failed: Resource temporarily unavailable on freebsd/386, netbsd/arm

[mikioh]

uname: FreeBSD 9.1-RELEASE-p2

gcc -v:
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 4.2.1 20070831 patched [FreeBSD]

hg id: 8633d8460c82 tip


just TestCgoSignalDeadlock fails,

--- FAIL: TestCgoSignalDeadlock (1.90 seconds)
    crash_cgo_test.go:21: expected "OK\n", but got "runtime/cgo: (snip)

then run cgoSignalDeadlockSource in crash_cgo_test.go and got a result below:

./cgotest
runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort
PC=0x881ae5fb


goroutine 1 [sleep]:
time.Sleep(0xf4240, 0x0)
    /home/mikioh/go/src/pkg/runtime/ztime_freebsd_386.c:19 +0x37
main.main()
    command-line-arguments/_obj/xxx.cgo1.go:50 +0xdf

goroutine 2 [syscall]:

goroutine 4 [running]:
main.func·003()
    command-line-arguments/_obj/xxx.cgo1.go:28 +0x91
created by main.main
    command-line-arguments/_obj/xxx.cgo1.go:39 +0x86

goroutine 6 [select (no cases)]:
main.func·004()
    command-line-arguments/_obj/xxx.cgo1.go:44 +0x1e
created by main.main
    command-line-arguments/_obj/xxx.cgo1.go:45 +0xbb

(snip)

[mikioh]

Comment 2:

Seems like it depends on the number of goroutines, funny.
If we change L61 of crash_cgo_test.go,
https://code.google.com/p/go/source/browse/src/pkg/runtime/crash_cgo_test.go
for example s/64/32/,  then test passes.

[dvyukov]

Comment 4:

Is it possible to create 100+ threads in C on the machine?

[mikioh]

Comment 5:

Never mind, or must be worried more, not sure.
Just tried the build w/ source but failed to repro.
(and C/C++ w/ or w/o boost but includes pthread
works fine; it runs up to 100+ threads, I mean, num
of filedescs and stacksize per process configuration
are enough to run pthread stuff.)
What? The only difference btw last night and now
would be... VM slept and resumed.
Hm... WDYT? Can you want to hold this issue or
to mark as retracted?

[adg]

Comment 6:

Let's hold onto it, but not for 1.1

Labels changed: removed go1.1.

[mikioh]

Comment 7:

http://build.golang.org/log/37aa5b438e899541ac0a8cae34a3cf83aa7c2645

[dvyukov]

Comment 9:

Let's close it. If/when you will be able to reproduce it, you may reopen this one, we
will need more information anyway.

Status changed to Retracted.

[minux]

Comment 10:

the runtime test still fails for netbsd/arm.
http://build.golang.org/log/b2a854589f11337dee2617e71f3c3e5ed66537d1
what information do you want?

[dvyukov]

Comment 11:

1. Is it possible to create the same number of threads in C/pthread program on the
machine?
2. Does the Go program creates an expected number of threads or much more than that?

[mikioh]

Comment 12:

Ans. 1 - yes, as mentioned at #5
Ans. 2 - ah, never tried, will try this weekend (stashed away freebsd/386 vm now).

[dvyukov]

Comment 13:

> Ans. 1 - yes, as mentioned at #5
#5 says that it's possible to create threads with C/pthread, but at the same time [Go]
build from source works as well. So it says nothing. What I want is:
Go create 1000 threads -> fail
C/pthread create 1000 threads -> OK
Go create 1000 threads -> fail
C/pthread create 1000 threads -> OK
Go create 1000 threads -> fail
C/pthread create 1000 threads -> OK
Go create 1000 threads -> fail
C/pthread create 1000 threads -> OK
What we have is:
Go create 1000 threads -> fail
day later:
C/pthread create 1000 threads -> OK
Go create 1000 threads -> OK

[mikioh]

Comment 14:

ah, I see.

[minux]

Comment 15:

to my surprise, the netbsd/arm does indeed have a ulimit for maximum
threads (ulimit -r) (the same ulimit doesn't exist on other platforms
like 386.)
i've raised it from 160 to 2048 and the netbsd-arm builder is green now.