Re: uw-threads issues

[Robert Lipe <robertl at sco dot com>]

I'm quite pleased that uw-threads has been added to GDB.  Special thanx
to Jason to helping work through some birthing pains getting it added.

There are currently two failure cases that are interesting.  While I
probably can't take these to the mat, I can be the fingers and eyes of
someone that understands the GDB threads system.

I have a threaded application that uses bound threads.  (Each
thread gets an LWP of its very own.)  This seems to give
uw-thread.c::libthread_stub() indigestion becuase it gets hammered with
tc_thread_continues on startup.

	Try POSIX INIT
	[New LWP 1]
	[New Thread 1]
	[New Thread 2]
	unexpected condition in libthread_stub()
	[New Thread 3]
	unexpected condition in libthread_stub()
	[New LWP 2]
	[New LWP 3]

I'm not certain this is a "real" problem, becuase GDB does indeed seem
to know about the newly created threads as shown by an 'info threads'.
This may be the actual root of the subsequent problems; I don't know.


The first "real" problem comes in thread.c::delete_thread().  The
second time it is called for this app, tp->private is bogus.  This
becomes a little easier to spot with 'nullptr disable' turned on, but
it still makes the system free() exceedingly unhappy.  For immediate
gratifcation, I just quit calling free(tp->private) and GDB quit
dropping core.

Try POSIX DEINIT
[Exited Thread 2]
Free tp->private 832c830
Free tp 832c7e0
[LWP 2 exited]
Free tp->private 3

Program received signal SIGSEGV, Segmentation fault.
0xbffadf4e in free () from /usr/lib/libc.so.1

Clearly, "3" is an address that malloc would never have returned.

The second one is more slippery.   I've never seen this problem running
on a uniprocessor configuration ('psradm -f -a') and it's intermittent
when running on a dual CPU config.   Once it happens, you're hosed.

procfs: store_registers, set_gregs line 3575, /proc/18907: Device busy.
(gdb) q
The program is running.  Exit anyway? (y or n) y
procfs: couldn't find pid 18907 in procinfo list.
(gdb) q
The program is running.  Exit anyway? (y or n) y
procfs: couldn't find pid 18907 in procinfo list.
(gdb) q
The program is running.  Exit anyway? (y or n) y
procfs: couldn't find pid 18907 in procinfo list.

This might actually be two problems.  One that set_gregs gets an EBUSY
but cannot cope and one that you can't quit GDB after this happens.  I'm
more interested in the first right now.

I don't see any sort of locking on the /proc accesses in
procfs.c::proc_set_gregs().  I don't know if it's busy becuase GDB is
whacking on it itself or if it's becuase someone else (libthread?) was
whacking on it. Truss on the target application shows no accesses to
/proc so I suspect that GDB is tripping over its own accesses.


Anyway, I hope this helps.  If you need additional information, please
contact me.

RJL