Getting SIGSEGV when debugging with gdb

resilva87 commented 8 years ago

Hi,

I'm creating a couple of applications and I believe one of the dependencies I'm using depends on this library. It seems that go-stack/stack causes a SIGSEGV error with gdb.

As I was trying to debug one of my applications, I got stuck with this error. I created two gists (gist1 and gist2) to showcase what's happening:

In gist1 I've simply copied and pasted the channels example from golang docs. After compiling the program with go build -gcflags "-N -l" main.go I started gdb with gdb main and was able to use it normally.
In gist2 I've changed the code to include the example in stack README file. Compiled the code go build -gcflags "-N -l" main.go and started gdb. After setting a breakpoint and running the code, gdb shows the error Thread 1 "main" received signal SIGSEGV, Segmentation fault. 0x000000000046c898 in github.com/go-stack/stack.findSigpanic.func1 (p=0x0, &fn=0xc820041f10, ~r0=0) at /opt/gopath/src/github.com/go-stack/stack/stack.go:228

Both versions of this example code are statically linked. stack library is built to master branch (not vendored).

Versions:

$ go version
go version go1.6 linux/amd64

$ gdb -v
GNU gdb (GDB) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".

ChrisHines commented 8 years ago

@resilva87 Thanks for filing an issue. The SIGSEGV you are seeing is quite intentional. You should be able to safely ignore it.

Justification

You can see the code that causes the SIGSEGV in the function findSigpanic. The code handles the signal with a deferred recover and continues gracefully. This code path is only executed once at program startup in order to cache the *runtime.Func for runtime.sigpanic.

runtime.sigpanic is important when processing stack traces returned from runtime.Callers because of an idiosyncrasy of how the Go runtime reports stack frames. This idiosyncrasy has always been present, but was first documented in Go 1.4. The documentation was updated in commit https://github.com/golang/go/commit/8db71d4ee89a505c375b550eb8fb8cc33bbabc03.

Unfortunately the *runtime.Func for runtime.sigpanic is not directly available to code outside of the runtime package. findSigpanic acquires it by dereferencing a nil pointer as a means to generate a stack trace that contains an entry for runtime.sigpanic.

Future changes

The just released Go 1.7 includes a new API for processing stack frames that handles the idiosyncrasies of runtime.FuncForPC for us. At some point I will update this package to use the new API when built using Go 1.7+, in which case it will no longer need to trigger a SIGSEGV at startup.

resilva87 commented 8 years ago

@ChrisHines that sounds great. Actually what I missed is that you can safely skip this signal in gdb http://stackoverflow.com/questions/23362984/gdb-nostop-sigsegv-on-a-specific-thread Thanks for the help! I think this can be closed

go-stack / stack

Getting SIGSEGV when debugging with gdb #4

Justification

Future changes