Check out my first novel, midnight's simulacra!

Core: Difference between revisions

From dankwiki
No edit summary
No edit summary
Line 15: Line 15:


==[[gcc]]==
==[[gcc]]==
(largely taken from the [http://valgrind.org/docs/manual/faq.html#faq.unhelpful Valgrind FAQ])
If they're not detailed enough, make sure you are compiling with -g to add debug information. And don't strip symbol tables (programs should be unstripped unless you run 'strip' on them; some libraries ship stripped). Also, -fomit-frame-pointer and -fstack-check can make stack traces worse.
Some example sub-traces:
* With debug information and unstripped (best):<pre>Invalid write of size 1
      at 0x80483BF: really (malloc1.c:20)
      by 0x8048370: main (malloc1.c:9)</pre>
* With no debug information, unstripped:<pre>Invalid write of size 1
      at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out)
      by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out)</pre>
* With no debug information, stripped:<pre>Invalid write of size 1
      at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out)
      by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out)
      by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
      by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out)</pre>
* With debug information and -fomit-frame-pointer:<pre>Invalid write of size 1
      at 0x80483C4: really (malloc1.c:20)
      by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
      by 0x80482CC: ??? (start.S:81)</pre>
* A leak error message involving an unloaded shared object:<pre>84 bytes in 1 blocks are possibly lost in loss record 488 of 713
      at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132)
      by 0x1DB63EEB: ???
      by 0x1DB4B800: ???
      by 0x1D65E007: ???
      by 0x8049EE6: main (main.cpp:24)</pre>

Revision as of 09:52, 5 April 2010

  • Produce a corefile for a running process with gcore(1)
  • The RLIMIT_CORE rlimit specifies the maximum size of a corefile (use 0 to disable corefile generation)

FreeBSD

  • sysctl kern.corefile controls naming mechanisms. See the core(5) man page.
  • sysctl kern.sugid_coredump controls whether processes with different effective and real U/GIDs produce corefiles
  • See savecore(8) and crashinfo(8) for further FreeBSD-specific capabilities

Linux

  • /proc/sys/kernel/core_pattern allows core naming to be configured (since Linux 2.6 and 2.4.21), and corefiles to be piped to programs. See the core(5) man page.
  • /proc/sys/kernel/core_uses_pid controls whether the PID is appended to the corefile's name
  • The prctl flag PR_SET_DUMPABLE allows process-specific coredump generation settings
  • /proc/sys/fs/suid_dumpable
  • /proc/PID/coredump_filter allows memory map-specific coredump generation settings

gcc

(largely taken from the Valgrind FAQ) If they're not detailed enough, make sure you are compiling with -g to add debug information. And don't strip symbol tables (programs should be unstripped unless you run 'strip' on them; some libraries ship stripped). Also, -fomit-frame-pointer and -fstack-check can make stack traces worse. Some example sub-traces:

  • With debug information and unstripped (best):
    Invalid write of size 1
      at 0x80483BF: really (malloc1.c:20)

by 0x8048370: main (malloc1.c:9)

  • With no debug information, unstripped:
    Invalid write of size 1
      at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out)

by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out)

  • With no debug information, stripped:
    Invalid write of size 1
      at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out)
      by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out)
      by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)

by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out)

  • With debug information and -fomit-frame-pointer:
    Invalid write of size 1
      at 0x80483C4: really (malloc1.c:20)
      by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)

by 0x80482CC: ??? (start.S:81)

  • A leak error message involving an unloaded shared object:
    84 bytes in 1 blocks are possibly lost in loss record 488 of 713
      at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132)
      by 0x1DB63EEB: ???
      by 0x1DB4B800: ???
      by 0x1D65E007: ???

by 0x8049EE6: main (main.cpp:24)