Re: accessing each pthread's context

Thanks for your reply.

Why do you need "stack traces for all running threads" to begin with?

Two reasons, only one of which applies :-)
- Creating an assertion log. Debugging is greatly facilitated
by knowing where each of the dozen or so closely
related threads is executing (or more likely blocked) and what
lead up to that state. The assertion log is the only information
we get (no core dump, and never a gdb session), so it helps
to get as much info as we can.
- And the second (irrelevant) reason: because its easy to do on
the two platforms where the software was developed (OS X,
and the usual culprit for "sloppy" aka convenient programming:
Win32.)

I think you mis-understood this part. It uses callbacks to read
the memory and registers of the debuggee, not to get the
pthread info.
I saw where libthread_db was grabbing register contents and
reading memory on the target process, and I assumed (!) that
was how gdb/libthread_db was handling threads. I'm curious if
libthread_db causes the target process to switch between
threads, and then use gcc's __builtin_frame_address and
__builtin_return_address to cause the thread to report its own
stack trace?

This will be *extremely* brittle solution:
IOW only an app built on the client machine is likely to work.
That pretty much rules out commercial software :-)

If your threads can cooperate on this, you could have them all
save their own "state" (e.g. via setjmp) and suspend themselves
on a mutex. This would be a much more portable solution.
That's the approach I've been hoping to avoid since its so much
more work and problematic when trying create a snapshot of the
application during a fatal assertion.

This may be one of the "features" that doesn't translate
well from OS X/Mach or Win32 to Linux/pthreads.

regards,
Brendan Creane

.