What is a good way to dump a Linux core file from

问题:

We have a server (written in C and C++) that currently catches a SEGV and dumps some internal info to a file. I would like to generate a core file and write it to disk at the time we catch the SEGV, so our support reps and customers don't have to fuss with ulimit and then wait for the crash to happen again in order to get a core file. We have used the abort function in the past, but it is subject to the ulimit rules and doesn't help.

We have some legacy code that reads /proc/pid/map and manually generates a core file, but it is out of date, and doesn't seem very portable (for example, I'm guessing it would not work in our 64 bit builds). What is the best way to generate and dump a core file in a Linux process?

回答1:

Google has a library for generating coredumps from inside a running process called google-coredumper. This should ignore ulimit and other mechanisms.

The documentation for the call that generates the core file is here. According to the documentation, it seems that it is feasible to generate a core file in a signal handler, though it is not guaranteed to always work.

回答2:

I saw pmbrett's post and thought "hey, thats cool" but couldn't find that utility anywhere on my system ( Gentoo ).

So I did a bit of prodding, and discovered GDB has this option in it.

gdb --pid=4049 --batch -ex gcore

Seemed to work fine for me.

Its not however very useful because it traps the very lowest function that was in use at the time, but it still does a good job outside that ( With no memory limitations, Dumped 350M snapshot of a firefox process with it )

回答3:

Try using the Linux command gcore

usage: gcore [-o filename] pid

You'll need to use system (or exec) and getpid() to build up the right command line to call it from within your process

回答4:

Some possible solutions^W ways of dealing with this situation:

1. Fix the ulimit!!!
2. Accept that you don't get a core file and run inside gdb, scripted to do a "thread all apply bt" on SIGSEGV
3. Accept that you don't get a core file and acquired a stack trace from within the application. The Stack Backtracing Inside Your Program article is pretty old but it should be possible these days too.

回答5:

You can also change the ulimit() from within your program with setrlimit(2). Like the ulimit shell command, this can lower limits, or raise them as hard as the hard limit allows. At startup setrlimit() to allow core dumping, and you're fine.

回答6:

I assume you have a signal handler that catches SEGV, for example, and does something like print a message and call _exit(). (Otherwise, you'd have a core file in the first place!) You could do something like the following.

void my_handler(int sig)
{
   ...
   if (wantCore_ && !fork()) {
      setrlimit(...);  // ulimit -Sc unlimited
      sigset(sig, SIG_DFL);  // reset default handler
      raise(sig);  // doesn't return, generates a core file
   }
   _exit(1);
}

回答7:

use backtrace and backtrace_symbols glibc calls to get the trace, just keep in mind that backtrace_symbols uses malloc internally and in case of heap corruption it might fail.

回答8:

system ("kill -6 ")

I'd give it a try if you are still looking for something