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

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

[Jonathan A. George]

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)

Environment:
Any 2.6 series kernel (tested 2.6.0 - 2.6.6 vanilla kernel.org)
Any GDB (tested 6.0 - current CVS)
Any GCC linked with -lpthread (tested 3.0.4 - 3.3.3)

GDB output from test program:
Detaching after fork from child process 7020.
warning: Unexpected waitpid result 00117f when waiting for vfork-done
linux-nat.c:450: internal-error: unknown ptrace event 5
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

Observations:
It seems as if GDB in linux-nat.c is trying to associate the vfork()d 
popen()d process with the root process instead of the parenting thread 
started by the root process.

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

[Daniel Jacobowitz]

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)
> 
> Environment:
> Any 2.6 series kernel (tested 2.6.0 - 2.6.6 vanilla kernel.org)
> Any GDB (tested 6.0 - current CVS)
> Any GCC linked with -lpthread (tested 3.0.4 - 3.3.3)
> 
> GDB output from test program:
> Detaching after fork from child process 7020.
> warning: Unexpected waitpid result 00117f when waiting for vfork-done
> linux-nat.c:450: internal-error: unknown ptrace event 5
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n)
> 
> Observations:
> It seems as if GDB in linux-nat.c is trying to associate the vfork()d 
> popen()d process with the root process instead of the parenting thread 
> started by the root process.

Did you really try current CVS?  I checked in a fix for this a couple
of weeks ago.

If it still doesn't work, please post a test case.

-- 
Daniel Jacobowitz

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

[Jonathan A. George]

[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]

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)
>>
>> Environment:
>> Any 2.6 series kernel (tested 2.6.0 - 2.6.6 vanilla kernel.org)
>> Any GDB (tested 6.0 - current CVS)
>> Any GCC linked with -lpthread (tested 3.0.4 - 3.3.3)
>>
>> GDB output from test program:
>> Detaching after fork from child process 7020.
>> warning: Unexpected waitpid result 00117f when waiting for vfork-done
>> linux-nat.c:450: internal-error: unknown ptrace event 5
>> A problem internal to GDB has been detected,
>> further debugging may prove unreliable.
>> Quit this debugging session? (y or n)
>>
>> Observations:
>> It seems as if GDB in linux-nat.c is trying to associate the vfork()d 
>> popen()d process with the root process instead of the parenting 
>> thread started by the root process.
>>   
>
>
> Did you really try current CVS?  I checked in a fix for this a couple
> of weeks ago.
>  
>
Technically I tried the current CVS snapshot, but to be sure I just 
checked out the entire tree using the following commands:

cvs -z2 -d :pserver:anoncvs@sources.redhat.com:/cvs/src co gdb+dejagnu
cvs -z2 up
./configure
make
su
make install

I even moved aside the distribution gdb:

su
cd /usr/bin
mkdir gdb.distro
mv *gdb* gdb.distro

One possible note of interest; when gdb starts for my test case I see 
these messages:

GNU gdb 2004-04-17-cvs
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db 
library
"/lib/tls/libthread_db.so.1".

(gdb) run
Starting program: /home/jageorge/example/a.out
[Thread debugging using libthread_db enabled]
[New Thread 1076200096 (LWP 30264)]
hello world
[New Thread 1084591024 (LWP 30267)]

> If it still doesn't work, please post a test case.
>
My test case is attached.

--Jonathan--


[-- Attachment #2: popen_pthread.cpp --]
[-- Type: text/x-c++, Size: 962 bytes --]

#include <iostream>
using namespace std;
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
void *
thread_start( void *thread_arg )
{
	cout << "arg=" << (long) thread_arg << endl;
	FILE *popen_file = popen( "ping -c3 127.0.0.1", "r" );
	cout << "errno=" << errno << endl;
	if( popen_file )
	{
		char linebuf[ 0xff ];
		char *fgets_result = NULL;
		while( NULL !=
			(fgets_result = fgets( linebuf, sizeof( linebuf ), popen_file )) )
		{
			cout << "fgets_result=" << fgets_result;//<< endl;
		}
		int pclose_result = pclose( popen_file );
		cout << "pclose_result=" << pclose_result << endl;
	}
	return( NULL );
}

int
main()
{
	cout <<  "hello world" << endl;
	pthread_t tid = 0;
	pthread_attr_t pattr;
	pthread_attr_init( &pattr );
	pthread_attr_setdetachstate( &pattr, PTHREAD_CREATE_DETACHED );
	pthread_create( &tid, &pattr, thread_start, (void *) 12345L );
	//pthread_join( tid, NULL );
	cout << "sleeping" << endl;
	sleep( 20 );
	return( 0 );
};

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

[Daniel Jacobowitz]

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