Re: BUG: GDB >=6 vfork from pthread fails with 2.6 vanilla kernels

[Daniel Jacobowitz <drow at false dot org>]

On Mon, May 17, 2004 at 12:39:49PM -0500, Jonathan A. George wrote:
> Daniel Jacobowitz wrote:
> 
> >On Fri, May 14, 2004 at 10:12:42AM -0500, Jonathan A. George wrote:
> > 
> >
> >>BUG: GDB >=6 vfork from pthread fails with 2.6 vanilla kernels
> >>
> >>Very simple to duplicate:
> >>Run popen() from within a pthread_create() thread while sleeping in 
> >>the base process.
> >>
> >>(NOTE: works perfectly outside of GDB and under GDB with 2.4 kernel 
> >>pthreads)

Hi Jonathan,

Sorry it's been so long since I got back to you about this problem.  I
haven't forgotten.  Here's the result of some investigation I did
today:

After vforking, the parent process is blocked, and will remain blocked
until the child process execs or exits, i.e. the time when the
VFORKDONE event is delivered.  "Blocked" corresponds to D state, what
the Linux kernel calls TASK_UNINTERRUPTIBLE.  During this time we can
not access it.  This is pretty unfortunate, because it means that (for
instance) if we try to read its memory we'll get an error.  This causes
us to decide that the thread is dead.  Therefore we reassign the event
to the remaining thread, and try to wait for the wrong thread.

This problem is specific to vfork; the patch I checked in this past
March fixed fork from threads, but not vfork.

Right now GDB stops at the point of the fork, so that the user can
choose which thread to follow.  It doesn't seem that this will work,
because we don't have complete control over the inferior.  It might be
possible to fix this in the kernel by changing the parent to the
stopped state at this point.  The latest Linux kernels have a separate
PTRACED state which would be appropriate.

I'm not sure if we can work around this problem in GDB or not.  This
isn't the first time that I've wanted to tell GDB "this process is
stopped, still alive, but not accessible for the moment".

-- 
Daniel Jacobowitz