How to read runtime panic output

[zfl_base]

Is there a doc/tutorial on how to read the runtime panic output?

I have a program using cgo to play with xlib and vulkan etc. And occasionally it got a runtime panic:

fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x8 pc=0x7f2e2b2e7920]

runtime stack:
runtime.throw(0x6d4aa0, 0x2a)
	/usr/lib/go-1.6/src/runtime/panic.go:547 +0x90
runtime.sigpanic()
	/usr/lib/go-1.6/src/runtime/sigpanic_unix.go:12 +0x5a

and it goes on to list some 36 goroutines.

I can’t even tell which goroutine is at fault. Is the top most listed goroutine supposed to be the bad guy? Does signal 0xb mean it’s a SIGSEGV? Is there a way that I can use printf to debug the situation? Or do I have to use a debugger such as gdb? (I really know close to zero about gdb.)

BTW, when I have Chinese/Japanese in the path name, and also uses cgo, then golang runtime cannot get the path correct. For example, panic outputs prints wrong path, and runtime.Caller() returns bad path, etc. This has troubled me for quite a few months now.

[dfc (Dave Cheney)]

The faulting goroutine is at the top. It caused the problem.

0xb is sigbus, which is caused by dereferencing a field of a pointer which is nil. The faulting address is 8, so 8 bytes beyond the start of the structure.

You cut off important part of the stack trace which tells you where in your code the fault happened. Upload the full trace for that goroutine and we can probably tell you what went wrong.

[dfc (Dave Cheney)]

Also, upgrade to go 1.6.2. Thanks.

[zfl_base]

Thank you!

It’s a race condition now resolved. I had a number of destroy operations hooked upon various channel closes and I failed to see that, when I close those channels one after another, those destroy operations would be in a race!

[dfc (Dave Cheney)]

Or better, go1.7beta2 which include some support for printing stack traces inside foreign c code.

[zfl_base]

I’m using go 1.6.2 debian package. It just puts the source in go-1.6 dir, but it’s really 1.6.2.

[dfc (Dave Cheney)]

You didn’t mention anything about a data race in your original post. This would have been useful information to include.

[zfl_base]

I didn’t know.

Only when I knew that the top goroutine is at fault, I stared it long enough to see it.

Thanks again!