Debugging core files with dbx

Question

Here are a few questions one of our developers asked me
to post:
There are some things I don't understand about these core files.
(I get this dbx message examining the core file: dbx: internal warning: writable memory segment 0xfe750000[188416] of size 0 in core)
Here are the threads:
(dbx) threads
> t@1 a l@1 ?() LWP suspended in elflookup_filtee()
t@2 a l@2 ?() LWP suspended in __open()
t@4 b l@4 kaiocleanup_thread() LWP suspended in kaio()
o t@5 a l@5 ?() signal SIGSEGV in runThreadFunction()
t@6 a l@6 ?() sleep on (unknown) in __lwp_park()
t@7 a l@7 ?() sleep on (unknown) in __lwp_park()
(dbx)
Here's thread 1:
(dbx) where
current thread: t@1
=>[1] elflookup_filtee(0xffbff29c, 0xffbff32c, 0xffbff328, 0x5af8f2f, 0x184, 0xff1208d8), at 0xff3b8e3c
[2] lookup_sym_interpose(0xffbff330, 0xffbff32c, 0xffbff328, 0x5af8f2f, 0x0, 0xff3c2bcc), at 0xff3b6a2c
[3] tls_report_modules(0xff3ec0f0, 0xfea905d0, 0x2380c, 0xff3ec0f0, 0xff3ee67c, 0x0), at 0xff3caeac
[4] rtboot(0x2380c, 0xff000000, 0x0, 0xfe8b6448, 0x0, 0xfe8e9c44), at 0xff3b378c
[5] 0x4aee0(0x4bfd8, 0x0, 0xff000000, 0x0, 0x0, 0xfe7f2000), at 0x4aedf
[6] 0x2380c(0x1, 0x1084, 0xfe797cc0, 0x0, 0xfe7f2000, 0x1000), at 0x2380b
[7] _exithandle(0xfe8e9b80, 0xfe797c00, 0xfe8e8bc0, 0x1, 0x4b104, 0xfc00), at 0xfe83e608
[8] exit(0x0, 0x1, 0x77c20, 0x4d000, 0xfe7974c0, 0xfe797500), at 0xfe82cf28
And here's thread 5:
(dbx) where -h
current thread: t@5
=>[1] DataWriter::runThreadFunction(0xffbff1a0, 0x0, 0x431bde83, 0x15a758, 0x0, 0x9f3e), at 0x1eba8
[2] 0xfeee5724(0xffbff1ac, 0xfe47c000, 0x0, 0x0, 0xffbff1a0, 0x4bb1c), at 0xfeee5723
(dbx)
What I dont understand:
1. Why is where on thread 5 not reporting the SEGV?
2. Why is thread 1 in the exit handle when some threads have not yet exited?
3. Why is thread 1 not showing any stack above the exit call?
How do I get information on these questions?
Thanks in advance.
-- prasad

Answer 1

which version of dbx are you using?
A message about "size 0" can sometimes mean that
your core file was truncated by a core limit that is set
too low. That can cause missing information.
1. Why is where on thread 5 not reporting the SEGV?I don't know. This seems like a bug, but not a serious one.
You know there is a seg fault from the "threads" command.
2. Why is thread 1 in the exit handle when some threads have not yet exited?The program can call exit() whenever it wants to. At that
point the cleanup handlers will be called. If you want the
system to wait for all threads to exit, then call thr_exit() instead
of exit().
3. Why is thread 1 not showing any stack above the exit call?I don't know the answer. Sometimes stack trace information
in the process is a little but unreliable. It's only 100% reliable if you
compile with -g and do not use the optimizer. Even in those cases,
it is 99% reliable.