Check out my first novel, midnight's simulacra!
Core: Difference between revisions
From dankwiki
(Created page with '==FreeBSD== * kern.corefile=/data/cores/%N-%U-%P.core * kern.sugid_coredump=1') |
mNo edit summary |
||
(5 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
* Produce a corefile for a running process with <tt>gcore</tt>(1) | |||
* The RLIMIT_CORE [[rlimit]] specifies the maximum size of a corefile | |||
** Use 0 to disable corefile generation, and "unlimited" for no explicit restriction on coredump size. | |||
** [[pam]] might be setting a hard limit at login time. Check <tt>/etc/security/limits.conf</tt>. | |||
==FreeBSD== | ==FreeBSD== | ||
* kern.corefile=/ | * sysctl <tt>kern.corefile</tt> controls naming mechanisms. See the <tt>core(5)</tt> 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 <tt>core(5)</tt> man page. | |||
* /proc/sys/kernel/core_uses_pid controls whether the PID is appended to the corefile's name | |||
* The [[Linux APIs|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 [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> |
Latest revision as of 02:25, 17 June 2011
- 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, and "unlimited" for no explicit restriction on coredump size.
- pam might be setting a hard limit at login time. Check /etc/security/limits.conf.
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)