Core: Difference between revisions

No edit summary
mNo edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
* Produce a corefile for a running process with <tt>gcore</tt>(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)
* 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==
* sysctl <tt>kern.corefile</tt> controls naming mechanisms. See the <tt>core(5)</tt> man page.
* sysctl <tt>kern.corefile</tt> controls naming mechanisms. See the <tt>core(5)</tt> man page.
Line 16: Line 17:
==[[gcc]]==
==[[gcc]]==
(largely taken from the [http://valgrind.org/docs/manual/faq.html#faq.unhelpful Valgrind FAQ])
(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.
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:
Some example sub-traces: