Core - revision history

Dank at 02:25, 17 June 2011

2011-06-17T02:25:56Z

← Older revision		Revision as of 02:25, 17 June 2011
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.

Dank: /* gcc */

2010-04-05T09:52:46Z

gcc

← Older revision		Revision as of 09:52, 5 April 2010
Line 16:		Line 16:
	==[[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:

Dank at 09:52, 5 April 2010

2010-04-05T09:52:28Z

Dank at 09:52, 5 April 2010

2010-04-05T09:52:00Z

← Older revision		Revision as of 09:52, 5 April 2010
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>

Dank at 09:48, 5 April 2010

2010-04-05T09:48:00Z

← Older revision		Revision as of 09:48, 5 April 2010
Line 13:		Line 13:
	* /proc/sys/fs/suid_dumpable		* /proc/sys/fs/suid_dumpable
	* /proc/PID/coredump_filter allows memory map-specific coredump generation settings		* /proc/PID/coredump_filter allows memory map-specific coredump generation settings

			==[[gcc]]==

Dank at 04:18, 17 June 2009

2009-06-17T04:18:36Z

@@ Line 1: / Line 1: @@
 ==FreeBSD==
-* kern.corefile=/data/cores/%N-%U-%P.core
+* sysctl <tt>kern.corefile</tt> controls naming mechanisms. See the <tt>core(5)</tt> man page.
-* kern.sugid_coredump=1
+* sysctl kern.sugid_coredump controls whether processes with different effective and real U/GIDs produce corefiles

Dank: Created page with '==FreeBSD== * kern.corefile=/data/cores/%N-%U-%P.core * kern.sugid_coredump=1'

2009-06-17T04:08:53Z

Created page with '==FreeBSD== * kern.corefile=/data/cores/%N-%U-%P.core * kern.sugid_coredump=1'

New page

==FreeBSD==
* kern.corefile=/data/cores/%N-%U-%P.core
* kern.sugid_coredump=1

← Older revision		Revision as of 09:52, 5 April 2010
Line 18:		Line 18:
	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:
	* With debug information and unstripped (best):<pre>Invalid write of size 1		* With debug information and unstripped (best):
			<pre>Invalid write of size 1
	at 0x80483BF: really (malloc1.c:20)		at 0x80483BF: really (malloc1.c:20)
	by 0x8048370: main (malloc1.c:9)</pre>		by 0x8048370: main (malloc1.c:9)</pre>
	* With no debug information, unstripped:<pre>Invalid write of size 1		* With no debug information, unstripped:
			<pre>Invalid write of size 1
	at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out)		at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out)
	by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out)</pre>		by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out)</pre>
	* With no debug information, stripped:<pre>Invalid write of size 1		* With no debug information, stripped:
			<pre>Invalid write of size 1
	at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out)		at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out)
	by 0x8048370: (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 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
	by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out)</pre>		by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out)</pre>
	* With debug information and -fomit-frame-pointer:<pre>Invalid write of size 1		* With debug information and -fomit-frame-pointer:
			<pre>Invalid write of size 1
	at 0x80483C4: really (malloc1.c:20)		at 0x80483C4: really (malloc1.c:20)
	by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)		by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
	by 0x80482CC: ??? (start.S:81)</pre>		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		* 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)		at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132)
	by 0x1DB63EEB: ???		by 0x1DB63EEB: ???