On Thu, May 29, 2003 at 03:24:53PM -0700, Bill Studenmund wrote:
> 
> I think _everyone_ want's to see more advanced methods of debugging
> threadded apps. I'm not sure if the tools are out there at all.

Well ok, that is true. :)  I guess I was thinking more along the lines
of ways to determine if it was the library or the app.  The assertions
in libpthreads help a lot for bad apps.

> What kind of issues?

Well, I have a Linux box running the pbx with a phone attached.  If I call
over to the NetBSD pbx to the demo extension it normally works, playing the
message, then it connects to the remote pbx which usually works.

If I hang up and call back the app freezes, but starts burning cpu.
Attaching with gdb shows the active thread is always in select().

If I kill -9 the process and start it again, it freezes immediately when
I attempt to connect.  If I reboot, it works the first time normally then
freezes.

So it seems like something is not getting cleaned up when I kill it, which
suggests the part that is hosed is not in the app, but in the kernel?

> > I will have to test it out more with a larger stack I guess, since it sounds
> > like that is a real limitation for some apps.
> 
> Try that...

Well so far with PT_STACKSIZE set to 512k I get an immediate segv like this:
(gdb) where
#0  0xbdbe7191 in pthread__lock_ras_start () from /usr/lib/libpthread.so.0
#1  0xbfbff5dc in ?? ()
#2  0xbdbe6b54 in pthread_mutex_lock () from /usr/lib/libpthread.so.0
#3  0xbdb4bcf9 in telldir () from /usr/lib/libc.so.12
#4  0xbdb4b274 in __opendir2 () from /usr/lib/libc.so.12
#5  0xbdb4ad9c in opendir () from /usr/lib/libc.so.12
#6  0x8053e19 in load_modules () at loader.c:361
#7  0x80768fd in main (argc=2, argv=0xbfbffc1c) at asterisk.c:1330
#8  0x8050534 in ___start ()

I am rebuilding libc now, in case there is some interaction.

-Andrew