From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paire To: "H . J . Lu" Cc: Mark Kettenis , GDB Subject: Re: Is the current gdb 5.1 broken for Linuxthreads? Date: Thu, 20 Sep 2001 00:59:00 -0000 Message-id: <200109200759.f8K7xGp02281@mailhost.ri.silicomp.fr> References: <20010919090519.B30455@lucon.org> X-SW-Source: 2001-09/msg00172.html > 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