runtime: core not dumped for crash from cgo #6988
Labels
Milestone
Comments
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
|
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);
}
|
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. |
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); |
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. |
|
This issue was closed by revision 0097d30. Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.The text was updated successfully, but these errors were encountered: