Re: How to make a core dump?

From: Glynn Clements (glynn.clements_at_virgin.net)
Date: 09/05/04

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

    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 <glynn.clements@virgin.net>
  • Next message: Beau Henderson: "Re: redhat patch problem?"

    Relevant Pages

    • Re: [2.6.27.24] Kernel coredump to a pipe is failing
      ... basic things like signals? ... Should dump_writetry again on ERESTARTSYS? ... When a signal happens during core dump the core dump to a pipe ... Based on debugging by Paul Smith. ...
      (Linux-Kernel)
    • Re: Process with many NPTL threads terminates slowly on core dump signal
      ... clear false pending signal indication in core dump ... > to terminate if it receives a signal that may cause a core dump. ... > program is designed to consume infinite CPU time). ... > * The slow process termination time only occurs for those signals that ...
      (Linux-Kernel)
    • Re: [PATCH] coredump: Retry writes where appropriate
      ... Core dump write operations (especially to a pipe) can be incomplete due ... In fact the signals checks were *purposefully added* some time ago. ...
      (Linux-Kernel)
    • Re: [2.6.27.24] Kernel coredump to a pipe is failing
      ... When a signal happens during core dump the core dump to a pipe ... can fail, because the write returns short, but the ELF core dumpers ... There's no reason to handle signals during core dumping, ...
      (Linux-Kernel)
    • Re: accessing each pthreads context
      ... and then appending a stack backtrace to ... an open file would most likely work. ... nondeterministic nature of mixing threads and signals and adding the ... building up a core dump over time by letting each thread add its ...
      (comp.programming.threads)