Re: How to make a core dump?

From: Glynn Clements (
Date: 09/05/04

  • Next message: Beau Henderson: "Re: redhat patch problem?"
    Date: Sun, 5 Sep 2004 06:54:18 +0100
    To: Alexander Morozov <>

    Alexander Morozov wrote:

    > recently my friend have found a malcious program running on his
    > web-server. After some actions i thought it would be helpful to make
    > its core dump, but i couldn't figure out how to do this. The only
    > thing that came to mind was attaching to it with gdb, stopping
    > it and dumping regions of memory manually (using memory map in
    > /proc/pid/mem). It went fine, i copied all segments but it would be much
    > better to have standart core dump, to be able to use usual programms on
    > it later. I remember, that several years ago default behaviour of a
    > program running under linux was dumping itself on SIGSEGV.
    > And I wonder, how was this fullfilled, was it feature of glibc to catch
    > SIGV and write a dump? Or was it made by the kernel?

    This is handled by the kernel; e.g. arch/i386/kernel/signal.c:

            case SIGQUIT: case SIGILL: case SIGTRAP:
            case SIGABRT: case SIGFPE: case SIGSEGV:
            case SIGBUS: case SIGSYS: case SIGXCPU: case SIGXFSZ:
                    if (do_coredump(signr, regs))
                            exit_code |= 0x80;

    However, all of the above signals can be caught (SIGKILL and SIGCONT
    can't be caught, but they don't cause a core dump). Also, the process'
    resource limits (specifically, RLIMIT_CORE) may prevent a core dump,
    or it may not have write permission to its current directory.

    It may suffice to simply send the program one of the above signals.
    However, if it's specifically trying to avoid this, you could try
    attaching gdb to the process then restoring the signal handler and
    resource limit before sending it the signal from within gdb.

    I dare say that there are other things which it could do if it was
    trying to thwart debugging attempts, e.g. having itself ptrace()d,
    continually changing its PID/PGID.

    Glynn Clements <>

  • Next message: Beau Henderson: "Re: redhat patch problem?"