On Monday 17 February 2003 11:15, Nathan J. Williams wrote:
>
> I should point out here that if you're relying on GDB to tell you
> where a segfault happened in a threaded app, you may get misleading
> results, because GDB doesn't know which thread caused the
> segfault. You need to use the GDB thread commands to poke around and
> find something that could have actually segfaulted (threads that
> "thread ex all" lists as being blocked or in the kernel are probably
> not the culprit).
> 
> I'm working on some GDB changes to make it easier to track these down;
> "watch this space" (or source-changes if you don't mind the volume).

Looks like I spoke too soon:

Program terminated with signal 11, Segmentation fault.
#0  0x86812c4 in pthread__switch ()
(gdb) info threads
  2 Thread 0  0x8685fef in _sys_select ()
  1 Thread 23  0x86813c5 in pthread__locked_switch ()
(gdb) thread ex all
0x48e00000: thread   23 sleeping on cond var at 0x8b7ddc0 
0x48dc0000: thread   22 zombie   
0x48d80000: thread   21 zombie   
0xbfbc0000: thread    0 in kernel
(gdb) 

Back to ddd and ktrace go I! :)