🚀 go-pugleaf

Hi,
I am also facing the same problem.
I am using RH 7.2 on IA32 box, with kernel 2.4.7-10.
U can reproduce (is it a bug????) this as follows. Use the test case given below.
[root@nadda randd]# cat test.c
#include <stdlib.h>

int main(int argc, char **argv) {
    char *p=getenv("MYTEST");

    printf("start of mytest\n");
    if (p==NULL) {
        printf("p is null\n");
        putenv("MYTEST=yes");
        printf("calling execvp %s\n",argv[0]);
        execvp(argv[0], argv);
    } else {
        printf("p = %s\n",p);
    }
    printf("rest of program...\n");
    printf("end of mytest\n");
    exit(0);
}
[root@nadda randd]# gcc -g -o test -lpthread test.c
[root@nadda randd]# gdb test
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 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 "i386-redhat-linux"...
(gdb) r
Starting program: /home/ansriniv/randd/test
[New Thread 1024 (LWP 4162)]
start of mytest
p is null
calling execvp /home/ansriniv/randd/test
Cannot find user-level thread for LWP 4162: generic error
(gdb) c
Continuing.
Cannot find thread 1024: generic error
(gdb)



doylep@eecg.toronto.edu (Patrick Doyle) wrote in message news:<699e3226.0203191209.403ad50e@posting.google.com>...
> Hi.  I hope this is helpful...
> 
> When debugging a program that uses pthreads, a call to execv causes
> gdb to get mighty confused:
> 
> (gdb) run
> Starting program: abc
> [New Thread 1024 (LWP 8440)]
> Breakpoint 2 (...)
> 736             execvp(argv[0], argv);
> (gdb) cont
> Continuing.
> Cannot find user-level thread for LWP 8445: generic error
> (gdb) bt
> Cannot find thread 1024: generic error
> (gdb) quit
> The program is running.  Exit anyway? (y or n) y
> Cannot find thread 1024: generic error
> (gdb) [5]   Terminated              gdb abc
> 
> [6]+  Stopped                 gdb abc
> [bash]$ kill %
> 
> [6]+  Stopped                 gdb abc
> [bash]$
> [6]+  Terminated              gdb abc
> [bash]$
> 
> This is Red Hat 7.2 and GNU gdb 20020225.

"Patrick Doyle" <doylep@eecg.toronto.edu> wrote in message
news:699e3226.0203191209.403ad50e@posting.google.com...
> Hi.  I hope this is helpful...
>
> When debugging a program that uses pthreads, a call to execv causes
> gdb to get mighty confused:
>
> (gdb) run
> Starting program: abc
> [New Thread 1024 (LWP 8440)]
> Breakpoint 2 (...)
> 736             execvp(argv[0], argv);
> (gdb) cont
> Continuing.
> Cannot find user-level thread for LWP 8445: generic error
> (gdb) bt
> Cannot find thread 1024: generic error
> (gdb) quit
> The program is running.  Exit anyway? (y or n) y
> Cannot find thread 1024: generic error
> (gdb) [5]   Terminated              gdb abc
>
> [6]+  Stopped                 gdb abc
> [bash]$ kill %
>
> [6]+  Stopped                 gdb abc
> [bash]$
> [6]+  Terminated              gdb abc
> [bash]$
>
> This is Red Hat 7.2 and GNU gdb 20020225.

Just wonder ...

What are you trying to achieve?
You replace the whole executable (if the exec.. succeeds) and would like to
get GDB keeping track of it. Besides, if there are other threads running,
they may get confused by the sudden replacement of the whole process code.

Tauno Voipio
tauno voipio @ iki fi

Hi,
I just want to gave a small test case for the problem reported by
Patrick.
My actual application is some thing different, however on the same
lines.
My application (it's a MT application) sets the LD_LIBRARY_PATH
(putenv(LD_LIBRARY_PATH)) from the executable path (i.e from argv[0])
and later part of the code uses the dlopen and creates threads.
Unfortunatly the dlopen is not able to see the change in the
LD_LIBRARY_PATH by the application. It only remembers the
LD_LIBRARY_PATH when it is execed. So i need to call the execvp with
the same application (by this time in my app, there won't be any
threads, except the main) somewhare between setting the path and
before using dlopen. And when i debug the application i am getting the
above mentioned error from gdb.
Cheers,
Srini



"Tauno Voipio" <tauno.voipio@iki.fi.SPAMBAIT_REMOVE> wrote in message news:<YXJn8.341$So2.49070@read2.inet.fi>...
> "Patrick Doyle" <doylep@eecg.toronto.edu> wrote in message
> news:699e3226.0203191209.403ad50e@posting.google.com...
> > Hi.  I hope this is helpful...
> >
> > When debugging a program that uses pthreads, a call to execv causes
> > gdb to get mighty confused:
> >
> > (gdb) run
> > Starting program: abc
> > [New Thread 1024 (LWP 8440)]
> > Breakpoint 2 (...)
> > 736             execvp(argv[0], argv);
> > (gdb) cont
> > Continuing.
> > Cannot find user-level thread for LWP 8445: generic error
> > (gdb) bt
> > Cannot find thread 1024: generic error
> > (gdb) quit
> > The program is running.  Exit anyway? (y or n) y
> > Cannot find thread 1024: generic error
> > (gdb) [5]   Terminated              gdb abc
> >
> > [6]+  Stopped                 gdb abc
> > [bash]$ kill %
> >
> > [6]+  Stopped                 gdb abc
> > [bash]$
> > [6]+  Terminated              gdb abc
> > [bash]$
> >
> > This is Red Hat 7.2 and GNU gdb 20020225.
> 
> Just wonder ...
> 
> What are you trying to achieve?
> You replace the whole executable (if the exec.. succeeds) and would like to
> get GDB keeping track of it. Besides, if there are other threads running,
> they may get confused by the sudden replacement of the whole process code.
> 
> Tauno Voipio
> tauno voipio @ iki fi

Can I suggest downloading a more recent snapshot of GDB.  See:

http://sources.redhat.com/gdb/current/

to see if the problem is still there?

Andrew