Comment 1:

GOTRACEBACK=2 gives me
SIGABRT: abort
PC=0x402230b
runtime.mach_semaphore_wait()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/sys_darwin_amd64.s:391 +0xb
runtime.mach_semacquire(0x1403, 0xffffffffffffffff)
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/os_darwin.c:426 +0xbe
runtime.semasleep(0xffffffffffffffff)
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/os_darwin.c:32 +0x58
runtime.notesleep(0x4117518)
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/lock_sema.c:159 +0xba
sysmon()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:2004 +0x196
runtime.mstart()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:485 +0xd2
goroutine 1 [runnable]:
runtime.park(0x4005f30, 0xc20008f000, 0x41153d6)
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:1175 +0x64
selectgo(0x43d8d70)
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/chan.c:989 +0x333
runtime.selectgo()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/chan.c:841 +0x12
main.main()
        command-line-arguments/_obj/bug.cgo1.go:133 +0x935
runtime.main()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:182 +0x92
runtime.goexit()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:1223
goroutine 2 [syscall]:
runtime.goexit()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:1223
goroutine 3 [syscall]:
runtime.entersyscallblock()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:1333 +0x16e
runtime.MHeap_Scavenger()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/mheap.c:435 +0xee
runtime.goexit()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:1223
created by runtime.main
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:165
goroutine 4 [runnable]:
runtime.exitsyscall()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:1388 +0x119
runtime.signal_recv(0xc20005a030)
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/zsigqueue_darwin_amd64.c:86 +0xdc
os/signal.loop()
        /Users/quarnster/code/3rdparty/go/src/pkg/os/signal/signal_unix.go:21 +0x1c
runtime.goexit()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:1223
created by os/signal.init·1
        /Users/quarnster/code/3rdparty/go/src/pkg/os/signal/signal_unix.go:27 +0x2f
goroutine 5 [syscall]:
runtime.entersyscallblock()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:1333 +0x16e
timerproc()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/ztime_darwin_amd64.c:195 +0xbc
runtime.goexit()
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/proc.c:1223
created by addtimer
        /Users/quarnster/code/3rdparty/go/src/pkg/runtime/ztime_darwin_amd64.c:82
rax     0xe
rbx     0x4117518
rcx     0xb00809e8
rdx     0x1
rdi     0x1403
rsi     0x0
rbp     0xffffffffffffffff
rsp     0xb00809e8
r8      0xb0080a48
r9      0x12
r10     0x0
r11     0x246
r12     0xfcd0294d0765
r13     0xfff4de99de68
r14     0x12f4b532268efc00
r15     0x40011e0
rip     0x402230b
rflags  0x246
cs      0x7
fs      0x0
gs      0x0

Comment 2:

Even simpler reproduction is at http://play.golang.org/p/RxLZLU9HhF. Usually I can just
press and hold ctrl+c for a short time and the hang happens. If it doesn't, hitting
ctrl+z to break out into the shell and then fg to go back and now holding ctrl+c, or
killing the process and trying again makes it hang.
The backtrace remains the same.
Also reproduces on OSX 10.7.4 with a brew installed python3.3.1 and:
09:10 ~ $ go version
go version devel +ce5b441d2fc6 Sun Apr 14 09:22:57 2013 +1000 darwin/amd64
09:11 ~ $ cc --version
Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.0
Thread model: posix
09:11 ~ $ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM
build 2336.9.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Comment 3:

Two syscall traces captured with dtruss from the launch of
http://play.golang.org/p/RxLZLU9HhF to the point of the hang are attached, one with back
traces enabled. Hitting ctrl+c in the hung state inserts further "17869/0x27f1f: 
sigreturn(0xC200052F48, 0x1E, 0x0)               = 0 Err#-2" in the trace buffer without
back tracing enabled.

Comment 4:

Apparently the attached files are lost if I fail typing in the correct captcha.

Attachments:

1. dtruss.txt (112171 bytes)
2. dtruss_s.txt (1165117 bytes)

Comment 5:

Can reproduce it.
It seems that runtime.sighandler() tries to grow stack.
newstack() finds m->curg==nil and crashes.
Don't know yet why it happens.

Comment 6:

runtime.sighandler should only be invoked from runtime·sigtramp in sys_darwin_amd64.s. 
That should ensure that m is set and that g is set to m->gsignal.  m->gsignal should
have enough stack space that sighandler does not need to grow the stack.  So perhaps the
first step is finding which in that set of steps is not happening.

Labels changed: added go1.1.

Comment 7:

>m->gsignal should have enough stack space that sighandler does not need to grow the
stack.
Yeah, but it does not check that rsp is actually inside of gsignal stack.

Comment 8:

PyInitialize messes with sigaltstack.
Please try the following patch and see whether it fixes the hang:
https://golang.org/cl/8777043/
I suspect that it actually can hang on other OSes and on Go1.0.3 as well. But it just
requires some special circumstances to occur.
This is quite risky to push it in into Go1.1. So I think it is at most Go1.1.1.
Ian, what do you think about the patch?
Runtime can not sustain arbitrary messing with system environment. For example, C code
can setup own signal handlers and that would break the runtime as well. So this change
is somewhat questionable. But I think we need to at least assert that SP belongs to
gsignal stack.

Labels changed: added priority-later, removed priority-triage, go1.1.

Owner changed to @dvyukov.

Status changed to Accepted.

Comment 9:

If I understand your description and your patch correctly, the problem is that some C
code called by Go called sigaltstack but did not override the Go signal handlers.  I
don't think it's reasonable to let two programs fight over the same signal handlers. 
Rather than an approach like your patch, perhaps it would make more sense to have some
way to disable the Go signal handlers.  Ultimately the two programs need to come to some
agreement on which is going to handle signals.

Comment 10:

>the problem is that some C code called by Go called sigaltstack but did not override
the Go signal handlers.
Maybe it has overridden the signal handlers but not all.
The problem is that Go and C handle disjoint sets of signals, but both want own
sigaltstack (which is not tied to a signal number).

Comment 11:

> Maybe it has overridden the signal handlers but not all.
Likely enough.  I don't think this affects my argument.  We need some way for the
programs to sensibly agree on what to do, not have them trying to second guess each
other.

Comment 12:

I have indeed been unable to reproduce the hang with the patch applied. Cheers!

Comment 13:

>We need some way for the programs to sensibly agree on what to do, not have them trying
to second guess each other.
We can provide an API for that, but it won't fix issues similar to this one. If you link
Python or a similar fat C library, I guess there are not much ways how you can affect
its behavior.

Comment 14:

issue #4216 sounds like it's related to this.

Comment 15:

Status changed to Duplicate.

Comment 16:

Merged into issue #4216.