runtime: core not dumped for crash from cgo

[ugorji]

I use cgo. I don't get a core dump when something goes wrong in the C code. I just get a
crash. This happens even when I run with expected environment parameters and ulimit set.

This makes debugging challenging. 

== Sample code: crash-cgo.go ==
package main

// void my_c_crash() { int* i = 0; *i = 2; } // NULL dereference will crash
import "C"

func main() {
    C.my_c_crash()
}

== Command line ==
ulimit -c unlimited; GOTRACEBACK=crash go run crash-cgo.go

I just get a stacktrace, as below:

SIGSEGV: segmentation violation
PC=0x400f67
signal arrived during cgo execution

runtime.cgocall(0x400f80, 0x7fc172103f40)
    /opt/go-tip/src/pkg/runtime/cgocall.c:149 +0x11b fp=0x7fc172103f28
main._Cfunc_my_c_crash(0x410e9f)
    /home/all/tmp/go-build893282196/command-line-arguments/_obj/_cgo_defun.c:51 +0x31 fp=0x7fc172103f40
main.main()
    /home/ugorji/depot/repo/src/cmd/scratch/test-cgo-crash.go:9 +0x1a fp=0x7fc172103f48
runtime.main()
    /opt/go-tip/src/pkg/runtime/proc.c:220 +0x11f fp=0x7fc172103fa0
runtime.goexit()
    /opt/go-tip/src/pkg/runtime/proc.c:1394 fp=0x7fc172103fa8

goroutine 2 [syscall]:
runtime.notetsleepg(0x7fc172121f60, 0xdf8475800)
    /opt/go-tip/src/pkg/runtime/lock_futex.c:190 +0x46
runtime.MHeap_Scavenger()
    /opt/go-tip/src/pkg/runtime/mheap.c:463 +0xa3
runtime.goexit()
    /opt/go-tip/src/pkg/runtime/proc.c:1394
created by runtime.main
    /opt/go-tip/src/pkg/runtime/proc.c:179

goroutine 3 [syscall]:
runtime.goexit()
    /opt/go-tip/src/pkg/runtime/proc.c:1394

rax     0xc
rbx     0x7fc172103f40
rcx     0xffffffffffffffff
rdx     0x7fc171ea19f0
rdi     0x420910
rsi     0x7fc1722d1000
rbp     0x6750e0
rsp     0x7fff7b07dcb0
r8      0xffffffff
r9      0x0
r10     0x22
r11     0x0
r12     0x400e60
r13     0x7fff7b07de10
r14     0x0
r15     0x0
rip     0x400f67
rflags  0x10246
cs      0x33
fs      0x0
gs      0x0
exit status 2

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Linux 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64
GNU/Linux

Which version are you using?  (run 'go version')
go version devel +04f0931c9808 Mon Dec 16 12:48:35 2013 -0800 linux/amd64

Please provide any additional information below.

[ianlancetaylor]

Comment 1:

The default behaviour is the traceback, as you see.  You can get a core dump by setting
the environment variable GOTRACEBACK=crash.

Status changed to WorkingAsIntended.

[ugorji]

Comment 2:

I did set the env variable and ulimit -c unlimited. 
See the bug report just below the line that said "command line", reproduced here:
    ulimit -c unlimited; GOTRACEBACK=crash go run crash-cgo.go
I expected to get the core dump, but I still only get the traceback. 
Some context leading to my filing this issue here:
https://groups.google.com/d/msg/golang-nuts/VB_9P29X040/56MEtpKu0QgJ

[ugorji]

Comment 3:

Please re-open the issue. It's a real issue.

[ianlancetaylor]

Comment 4:

My apologies, I missed that you were setting GOTRACEBACK.

Labels changed: added repo-main, release-go1.3.

Status changed to Accepted.

[minux]

Comment 5:

this is working as intended on darwin/amd64 (see comment in signal_unix.c).
For linux, this is because somehow the SIGABRT signal is blocked in the cgo
thread.
for example, this patch could fix the problem on linux (only):
diff -r acad7f360212 src/pkg/runtime/signal_unix.c
--- a/src/pkg/runtime/signal_unix.c Thu Dec 19 21:37:44 2013 +0100
+++ b/src/pkg/runtime/signal_unix.c Thu Dec 19 16:19:16 2013 -0500
@@ -112,7 +112,10 @@
    if(sizeof(void*) == 8)
        return;
 #endif
+   Sigset zero;
+   runtime·memclr((byte *)&zero, sizeof zero);
 
+   runtime·rtsigprocmask(SIG_SETMASK, &zero, &old, sizeof old);
    runtime·setsig(SIGABRT, SIG_DFL, false);
    runtime·raise(SIGABRT);
 }

[ianlancetaylor]

Comment 6:

Thanks, when you put it that way the problem is obvious: the call to sigaction in
runtime·setsig sets the signal mask to block all signals while executing the signal
handler.  Calling runtime·setsig again does not change the fact that the code is
executing inside a signal handler and the SIGABRT signal is blocked.  It would be
received when the signal handler returns and signals are unblocked, but of course the
code instead simply exits before that happens.

[minux]

Comment 7:

yeah, could we explicitly SIGABRT in the initial signal masks?
or should we add explicit unblock code to runtime.crash?

[ianlancetaylor]

Comment 8:

I think explicit unblocking would be mildly preferable, because easier to understand.
Interestingly I have this code in the gccgo runtime for any signal that may cause a
panic.
  /* The signal handler blocked signals; unblock them.  */
  i = sigfillset (&clear);
  __go_assert (i == 0);
  i = pthread_sigmask (SIG_UNBLOCK, &clear, NULL);
  __go_assert (i == 0);

[minux]

Comment 9:

OK, then I will first do some code refactoring because the current sigprocmask functions
have different prototypes (and even names) on different Unixes.

Owner changed to @minux.

Status changed to Started.

[minux]

Comment 10:

https://golang.org/cl/44070046/

[minux]

Comment 11:

This issue was closed by revision 0097d30.

Status changed to Fixed.

[davecheney]

Comment 12:

I would like to vote for merging this change into 1.2.1.

Labels changed: added release-go1.2.1, removed release-go1.3.

[rsc]

Comment 13:

Dave Cheney, why? It seems unimportant to me. Hardly a "critical bug fix".

[davecheney]

Comment 14:

@rsc because GOTRACEBACK=crash was broken. However on reflection I agree this doesn't
warrant back porting.

[rsc]

Comment 15:

Labels changed: added release-go1.3, removed release-go1.2.1.