Comment 1:

is there a way to force dump core (if `ulimit -c` > 0) without using signals?

Comment 2:

At least on traditional Unix systems the only way to get a core dump is via a signal.  I
don't know of any other way even on new systems.
I think that means that we need a runtime function for this, to reset the signal handler
for some core-dumping signal (e.g., SIGABRT) to the default, and then to send that
signal to the process.
Alternatively, we could avoid installing a signal handler for SIGABRT, and leave it
available to generate a core dump.  I think it's unusual for a program to want to handle
SIGABRT in any other way.

Comment 3:

We've established kill -ABRT as an idiom for getting goroutine stack
traces. I think people will be disappointed if it starts dumping core
instead. I agree that we should add some kind of runtime.Crash that
triggers the usual crash handling.

Comment 4 by viriketo:

Some people are used to get the stack traces with SIGABRT (C-\), some people are used to
SIGQUIT, iirc. I personally use C-\ always.
A runtime.Crash() would be great, but I'd like also a signal.
What's the use of SIGTRAP, outside a debugger? Maybe it fits? Then runtime.Breakpoint()
could be used for that too.

Comment 5:

i think we can replace runtime.exit(2) in runtime.dopanic() to abort() [set SIGABRT to
default actions and send
itself a SIGABRT] to achieve the generate a core at panic if allowed.

Comment 6:

I don't think we want a core dump by default when a Go program panics.  That's what the
stack trace is for.
If you want a core dump on a signal, use os/signal and call runtime.Crash when you get
that signal.

Comment 7:

FYI: C-\ will send SIGQUIT to the foreground process.
and i usually use that to get a stack trace.
adding runtime.Crash() won't address the problem of turning unhandled panics into a
core dump (you can't always control every goroutine created).

Comment 8:

when a program panics, it's often in a inconsistent state, so relying on Go code to
handle
core dump is not reliable.
Thus, perhaps we could introduce this to runtime/debug package.
// after calling CoreDumpWhenPanic(), if a panic is not recovered, the program will
// dump core (if the OS allows) after outputting normal crash stack traces to stderr.
func CoreDumpWhenPanic()
to enable the core dump on panic behavior.

Comment 9 by viriketo:

Most people disable coredumps. I think that trying to get core dumps on every panic
looks fine to me, and people won't be bothered with more core dumps than what would get
with non-go processes.

Comment 10:

Core dumps by default is not an option, sorry.

Comment 11:

now i think that instead of introducing a new non-portable API (as no concept of
coredump exists on windows), we might well just define a new environment
variable, GOCOREDUMP=1, or something like that), we don't need to document
it and it remains purely as a undocumented debugging trick (like GOTRACEBACK
and GOGCTRACE).
What do you think about this proposal?

Comment 12 by viriketo:

In windows there are minidumps. Very usual.
I also like the envvar approach, as other go runtime configuration.

Comment 13:

Labels changed: added priority-later, removed priority-triage.

Status changed to Thinking.

Comment 14:

Random other thoughts:
We enable GOGCTRACE for our services. Very useful to understand why production code is
pausing. No need to leave these goodies completely undocumented. :-)
ulimit -c is typically 0 on Fedora and you have to set it to something bigger to get
core dumps from C services. It would be nice if this thing works the same.
Might be worth reading through here a bit:
http://fedoraproject.org/wiki/StackTraces#Daemons_and_their_spawn
Making it work like C services means this kind of stuff keeps working:
http://www.freedesktop.org/software/systemd/man/systemd-coredumpctl.html

Comment 15:

More about how systemd's thing work:
http://stackoverflow.com/questions/2065912/core-dumped-but-core-file-is-not-in-current-directory
/proc/sys/kernel/core_pattern can take a | which means to run a command.

Comment 16:

Status changed to Duplicate.

Merged into issue #3257.