Re: Is the current gdb 5.1 broken for Linuxthreads?

[Eric Paire <paire@ri.silicomp.fr>]

> On Wed, Sep 19, 2001 at 04:38:51PM +0200, Eric Paire wrote:
> > > BTW, debugging threaded apps under Linux will always be somewhat
> > > fragile as long as there isn't a sane kernel threads interface to the
> > > kernel.  There should be an interface to stop all threads in a
> > > synchronous way.  Unfortunately, I have no hope that such an interface
> > > will be added to the kernel.
> > > 
> > I don't agree with you: There are at least 2 bugs in the current Linux
> > kernel which makes you think that the support is fragile:
> > 1) SIGSTOP management is not-POSIX conformant
> > 2) reparenting of debugged processes is buggy
> > 
> 
> Could you please provide testcases for them? Even better, do you have
> kernel patches?
> 
For 1), this is not very difficult to show, and I have always wondered why
so few people complained about it. The main effect of SIGSTOP in gdb is that
it makes GDB intrusive in the application, as sending SIGSTOP to a process
wakes it up if it was already sleeping in the kernel, and making the blocked
system call returning EINTR.

For most of the cases, this is hidden by the libc which wraps around system
calls the EINTR errno (such as for pthreads synchronization), but not for
all. The general philosophy of the SIGSTOP/SIGCONT is that a process receiving
SIGSTOP while being blocked in the kernel should be prevented from returning
to user space if unblocked (while in Linux it returns to user space with
EINTR), which is the point why GDB is not intrusive in many UNIX, and is
instrusive with Linux. By there are so many modifications to do in the
kernel that nobody (yet) has started to implement a correct semantics for
SIGSTOP/SIGCONT (as most of the problems are hiddden in the glibc).

For 2) here is the following scenario that did not work in linux-2.2.0:
Process A forks process B and process C (gdb, ...) calls ptrace_attach()
on process B. If process C (gdb) exits without calling ptrace_detach()
on process B, then
	a) process B is inherited by init task (instead of process A),
	b) if process A is blocked in wait4(), then it will not be
		awaken if process B dies (since process B is now child of
		init).

I must admit that I have not checked that problem 2) still exist on linux-2.4,
but it is clear that this is not an issue for GDB (as we can hope that gdb
is fair with the kernel, it always calls ptrace_detach() before exiting ;-).

Hope this helps,
-Eric
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE
Web  : http://www.ri.silicomp.com/~paire  | Groupe SILICOMP - Research Institute
Email: eric.paire@ri.silicomp.com         | 2, avenue de Vignate
Phone: +33 (0) 476 63 48 71               | F-38610 Gieres
Fax  : +33 (0) 476 51 05 32               | FRANCE