How can I get core dumps?

[Lluís Batlle i Rossell]

Hello,

I've some go programs that fail rarely, and I find the backtrace information
like not enough for what I need.

What line of go code can I add to my programs (like would be
runtime.Breakpoint()) so that they generate a core dump?

Having a gdb attached every time is not what I want, btw. :)

I'm on linux.

Regards,
Lluís.

[Ian Lance Taylor]

On Fri, Mar 1, 2013 at 8:27 AM, Lluís Batlle i Rossell <vi...@viric.name> wrote:
>
> I've some go programs that fail rarely, and I find the backtrace information
> like not enough for what I need.
>
> What line of go code can I add to my programs (like would be
> runtime.Breakpoint()) so that they generate a core dump?

I don't think there is a way to do this in pure Go code. Please open
an issue for this. I doubt it will be fixed for Go 1.1, but we might
as well provide some way to do it. Thanks.

Ian

[Rob Pike]

How about

runtime.Breakpoint()

How about

var p *int
*p = 0

Run in a debugger or set your environment up so you get core files.

I might not be understanding the problem.

-rob

[Lluís Batlle i Rossell]

On Fri, Mar 01, 2013 at 10:13:13AM -0800, Rob Pike wrote:
> How about
>
> runtime.Breakpoint()
>
> How about
>
> var p *int
> *p = 0

If I do any of that, I get SIGTRAP caught or 'nil pointer dereference', and
backtraces of goroutines on stderr.

> Run in a debugger or set your environment up so you get core files.

If the environment is 'ulimit -S -c unlimited', it doesn't help getting core
dump files with that means.

> I might not be understanding the problem.

Maybe it's me who doesn't understand something trivial. :)

Thank you,
Lluís.

[Steve McCoy]

It sounds like you want the Go runtime's top-level panic handler to give you a core dump rather than print the backtrace. I don't think this behavior can be customized, and even if it were possible, I don't think there would be much that you could investigate in the core dump, because the signal will be raised far from the code that caused the panic, deferred functions would have been run, and maybe more reasons that I can't think of. You would instead have to modify the panic function to send one of the core-instigating signals listed in signal(7) to the process. Of course, this would break the semantics of panic and you'd have to modify the runtime to do it.

One thing you can try is to use the backtrace info given to you to get some idea of where the error is happening, then add a "recover" block nearby, and have the recovery code do something like "syscall.Kill(syscall.Getpid(), syscall.SIGQUIT)". Maybe this will help you get better info, maybe it will be worthless; I've never tried it, because I just thought of it. Good luck.

[minux]

On Sat, Mar 2, 2013 at 5:23 AM, Steve McCoy <mcc...@gmail.com> wrote:

One thing you can try is to use the backtrace info given to you to get some idea of where the error is happening, then add a "recover" block nearby, and have the recovery code do something like "syscall.Kill(syscall.Getpid(), syscall.SIGQUIT)". Maybe this will help you get better info, maybe it will be worthless; I've never tried it, because I just thought of it. Good luck.

by default the Go runtime catches SIGQUIT so sending a Go program a SIGQUIT won't

trigger a crash dump.

in fact, sending SIGQUIT/SIGABRT (esp. the former with ^\) is an idiomatic way to kill the Go

process and generate a complete stack dump of all running goroutines.

see https://code.google.com/p/go/issues/detail?id=4959 for the reported issue.

[Steve McCoy]

Ha, I see it's all been covered there. Thanks for the link!