[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Where's my core file ?




On Tue, 21 Aug 2001, Oded Arbel wrote:

> I don't know - on one of our systems (stock mandrake kernel 2.4.3) whenever
> a thread (but not the main thread) crashes, it generates a core for every
> thread on the application (including the main thread).

then it _might_ be that they somehow fixed this on kernel 2.4 - on kernel
2.2 i _know_ this does not work. here is an excertp from the linux threads
FAQ, which seems to be updated for redhat 6.2 (which runs a 2.2. kernel):

---------------------------------------------------------------------
http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html

G.2: Does it work with post-mortem debugging?

Not very well. Generally, the core file does not correspond to the thread
that crashed. The reason is that the kernel will not dump
core for a process that shares its memory with other processes, such as
the other threads of your program. So, the thread that crashes
silently disappears without generating a core file. Then, all other
threads of your program die on the same signal that killed the
crashing thread. (This is required behavior according to the POSIX
standard.) The last one that dies is no longer sharing its memory
with anyone else, so the kernel generates a core file for that thread.
Unfortunately, that's not the thread you are interested in.
---------------------------------------------------------------------

so this explains the problems on the machine with kernel 2.2. that you
mentioned.

then, you can read what alax cox said to someone askng a similar question,
regarding RH7.1 (kernel 2.4.2-2).
taken from
http://www.linuxarkivet.nu/mlists/linux-kernel/0106/msg04790.html:

----------------------------------------------------------------------
To: yahui(a)gambitcomm.com (Yahui Lin)
     Subject: Re: core dump problem with a multi-threaded program
     From: Alan Cox <alan(a)lxorguk.ukuu.org.uk>
     Date: Fri, 29 Jun 2001 18:44:20 +0100 (BST)


 > multi-threaded program is not possible under RedHat Linux 7.1 (kernel
 > version 2.4.2-2), because loading the core into gdb 5.0 does not show
 > the correct crash location.

 2.4.2 doesn't support multithreaded core dumps.
 The RH errata kernel will generate a dump for each thread as/if/when that
thread
 crashes

 You can then inspect the relevant core.pid file, I've no idea how well
the
 gdb thread stuff works with it.

 -
----------------------------------------------------------------------

finally, read the following thread frm the linux kernel mailing list,
circa february 2001:

http://uwsg.iu.edu/hypermail/linux/kernel/0102.3/0549.html

i think you should realy enhance your googling techniques - you could have
found all this information yourself.

> It is important to get a core for each thread,so you can know the status of
> your application at the time of the crash - and the stacks of each thread is
> a very important clue in it - other wise I may not even know where in the
> application it crashes...

you tell me that? but until you have this worked out - you still need to
debug your application, and running it under gdb while its being
developed, and during early stages of testing - is an acceptable
compromise. and placing lots of asserts() and logging code is a good thin
in any event.

--
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy


=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il