Re: threads/2149: thread_db_get_info: cannot get thread info: generic error on fork()/execvp()

Re: threads/2149: thread_db_get_info: cannot get thread info: generic error on fork()/execvp()

[Alex Bligh]

The following reply was made to PR threads/2149; it has been noted by GNATS.

From: Alex Bligh <alex@alex.org.uk>
To: Daniel Jacobowitz <drow@false.org>
Cc: "Matthew M. DeLoera" <mdeloera@exacq.com>,
	gdb-gnats@sources.redhat.com
Subject: Re: threads/2149: thread_db_get_info: cannot get thread info: generic
 error on fork()/execvp()
Date: Sun, 13 Aug 2006 21:36:55 +0100

 The following pretty trivial program replicates the problem
 100% of the time. Thanks to Matthew for the hint. I suspect
 you only need 2 threads to join. Compile instructions
 included.
 
 Alex
 
 
 /* pth_dmo.c - pthreads demo.
   *
   *   SYNOPSIS
   *gcc -D_REENTRANT -lpthread -o pth_dmo pth_dmo.c
   *./pth_dmo
   *
   *   DESCRIPTION
   *Starts an arbitrary number of threads that do essential-
   *ly nothing but print the sequence number they were started
   *in. Uses pthread_join to "reap" the started threads.
   *
   *If nothing is done to synchronize the threads, usually
   *no output will appear;  otherwise,  you should see
   *
   *    Thread 1 reporting
   *    Thread 2 reporting
   *    Thread 3 reporting
   *
   *   PTHREAD_JOIN (See man pthread_join)
   *
   *int pthread_join(pthread_t th, void **thread_return);
   *
   *pthread_join  suspends  the  execution  of the calling
   *thread until the thread identified by th terminates,
   *either by  calling  pthread_exit(3) or by being cancel-
   *led.  The location pointed to by the thread_return arg-
   *ument contains the exit status of thread th; it can be
   *NULL.  The integer returned is zero if everything went
   *alright, which it usually does in this simple program.
   *
   *   ACKNOWLEDGEMENTS
   *       http://dis.cs.umass.edu/~wagner/threads_html/sect2.html
   *http://www.math.arizona.edu/swig/pthreads/threads.html#news
   */
 
 #include <sys/types.h>
 #include <pthread.h>
 #include <unistd.h>
 #include <stdio.h>
 
 void pr_my_id( void *arg )
 {
    int myid = * (int *) arg;
    printf ("Thread %d reporting\n", myid);
 }
 
 main()
 {
    pthread_t t1, t2, t3;
 
    int id1 = 1,
      id2 = 2,
      id3 = 3;
 
    int err;
 
    pid_t pid;
 
    /*  Start three threads ... */
    pthread_create ( &t1, NULL, (void *) &pr_my_id, (void *) &id1 );
    pthread_create ( &t2, NULL, (void *) &pr_my_id, (void *) &id2 );
    pthread_create ( &t3, NULL, (void *) &pr_my_id, (void *) &id3 );
 
    /*  Join them in order. */
    if  ( err = pthread_join(t1, NULL) )
      printf ("join of t1 failed\n");
    if  ( err = pthread_join(t2, NULL) )
      printf ("join of t2 failed\n");
    if  ( err = pthread_join(t3, NULL) )
      printf ("join of t3 failed\n");
    /*
      sleep(1);
    */
 
    pid = fork();
    if (pid == -1)
      printf ("fork() failed\n");
    else
      {
        if (pid)
          {
            int status;
            printf("I am the parent\n");
            waitpid(pid, &status, 0);
          }
        else
          {
            printf("I am the child\n");
            sleep(1);
            exit(0);
          }
      }
 
    printf ("Done\n");
 
    exit(0);
 }
 
 

Re: threads/2149: thread_db_get_info: cannot get thread info: generic error on fork()/execvp()

[drow]

Synopsis: thread_db_get_info: cannot get thread info: generic error on fork()/execvp()

Responsible-Changed-From-To: unassigned->drow
Responsible-Changed-By: drow
Responsible-Changed-When: Sun Sep 10 16:29:39 2006
Responsible-Changed-Why:
    Mine.
State-Changed-From-To: open->feedback
State-Changed-By: drow
State-Changed-When: Sun Sep 10 16:29:39 2006
State-Changed-Why:
    This should now be fixed in CVS, with what I just committed.  Want to give it a try?

http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2149

Re: threads/2149: thread_db_get_info: cannot get thread info: generic error on fork()/execvp()

[Alex Bligh]

The following reply was made to PR threads/2149; it has been noted by GNATS.

From: Alex Bligh <alex@alex.org.uk>
To: Daniel Jacobowitz <drow@false.org>
Cc: "Matthew M. DeLoera" <mdeloera@exacq.com>,
	gdb-gnats@sources.redhat.com
Subject: Re: threads/2149: thread_db_get_info: cannot get thread info: generic
 error on fork()/execvp()
Date: Sun, 13 Aug 2006 21:10:18 +0100

 Daniel Jacobowitz wrote:
 > This should now be fixed in the CVS repository, at least as long as you
 > aren't trying to follow the child of the fork.  Could you give it a
 > try?
 
 Apologies for the late response. I can confirm that this is
 *NOT* fixed. However, the symptom has changed. Using
 GNU gdb 6.5.50.20060813-cvs, the error I get is
 "Couldn't get registers: No such process." - this is
 with follow-fork-mode set to parent.
 
 With the original version of gdb (GNU gdb 6.4-debian, from
 Ubuntu Dapper), I get:
 thread_db_get_info: cannot get thread info: generic error
 (as originally reported).
 
 So you are somewhere near the error, but not quite there.
 
 I've also confirmed the original bug on both i386 and x86_64 Linux.
 
 I can replicate this 100% of the time (on my own, large, app,
 naturally, as having a simple sample to do it would make things
 much too easy). Get any version of Xara Xtreme from
    http://www.xaraxtreme.org/
 and run it under gdb. Whenever it executes an external program,
 it hangs under gdb. The easiest case is to install imagemagick,
 draw anything, then try an export a PSD file. If you've
 installed from a package, loading any file will do it as
 the extensible filter system will try executing one of the
 filters.
 
 Alex

Re: threads/2149: thread_db_get_info: cannot get thread info: generic error on fork()/execvp()

[Matthew M. DeLoera]

The following reply was made to PR threads/2149; it has been noted by GNATS.

From: "Matthew M. DeLoera" <mdeloer@aol.com>
To: gdb-gnats@sources.redhat.com
Cc: alex@alex.org.uk, drow@false.org
Subject: Re: threads/2149: thread_db_get_info: cannot get thread info: generic
 error on fork()/execvp()
Date: Tue, 01 Aug 2006 12:32:00 -0400

 Thanks for the quick response.
 
 I downloaded, built, installed, and ran gdb-6.5.50.20060801.tar.bz2 - I 
 ran .configure, make, and make install. When I ran gdb, I saw "GNU gdb 
 6.5.50.20060801".
 
 Unfortunately, it's still not working. When I attempt a fork after a 
 thread has previously ended, gdb responds with "Couldn't get registers: 
 No such process.".
 
 I also made sure that follow-fork-mode was still set to parent. For the 
 record, I don't have a need to follow the child anyway. I want to stay 
 with the parent.
 
 Thanks!
 
 - Matthew
 

Re: threads/2149: thread_db_get_info: cannot get thread info: generic error on fork()/execvp()

[Daniel Jacobowitz]

The following reply was made to PR threads/2149; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: alex@alex.org.uk, "Matthew M. DeLoera" <mdeloera@exacq.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: threads/2149: thread_db_get_info: cannot get thread info: generic error on fork()/execvp()
Date: Mon, 31 Jul 2006 09:00:01 -0400

 On Tue, Jul 18, 2006 at 12:42:06PM -0000, alex@alex.org.uk wrote:
 > On certain calls to fork(), execvp(), gdb does the following:
 >   thread_db_get_info: cannot get thread info: generic error
 > after that it is unusable.
 
 This should now be fixed in the CVS repository, at least as long as you
 aren't trying to follow the child of the fork.  Could you give it a
 try?
 
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

Re: threads/2149: thread_db_get_info: cannot get thread info: generic error on fork()/execvp()

[Matthew M. DeLoera]

The following reply was made to PR threads/2149; it has been noted by GNATS.

From: "Matthew M. DeLoera" <mdeloera@exacq.com>
To: gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: threads/2149: thread_db_get_info: cannot get thread info: generic
 error on fork()/execvp()
Date: Wed, 26 Jul 2006 17:46:40 -0400

 I find that this is consistently caused by the following sequence:
 
 1) Process A Thread 1 creates Thread 2.
 2) Process A Thread 2 ends.
 3) Process A forks.
 
 GDB will consistently give the aforementioned error on the fork, and 
 will interrupt. I find the same behavior with GDB 6.3 - 6.5 as of today. 
 I will mention that I saw this running openSUSE and Ubuntu 6.06, both 
 with gcc 4.0.3 and the 2.6 kernel.
 
 I did NOT see this problem on a Debian system with a 2.4 kernel, gcc 3, 
 and gdb 6.3.
 
 Another thing to note is that I think the problem is specifically that 
 once a process starts, it can freely fork until one of its threads ends. 
 Afterward, any fork call from any of its remaining threads will cause 
 the problem. Any other processes are oblivious of this. So, what I can 
 do is the surrogate parent model from the O'Reilly Pthreads book. If I 
 fork a child process any time before the parent process encounters any 
 of its threads ending, the child process continues to be able to freely 
 fork processes, regardless of thread activity in the parent process.
 
 While the first sequence consistently fails in GDB, a sequence that 
 follows the surrogate parent model consistently works.
 
 Hope this helps. In any case, I hope someone has a chance to look at 
 this? Thanks!

threads/2149: thread_db_get_info: cannot get thread info: generic error on fork()/execvp()

[alex]

>Number:         2149
>Category:       threads
>Synopsis:       thread_db_get_info: cannot get thread info: generic error on fork()/execvp()
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 18 12:48:01 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     alex@alex.org.uk
>Release:        GNU gdb 6.4-debian
>Organization:
>Environment:
Ubuntu Dapper, stock gdb, stock C compiler, stock libraries
Linux polonius 2.6.15-26-amd64-generic #1 SMP PREEMPT Mon Jul 17 19:50:04 UTC 2006 x86_64 GNU/Linux
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
GNU gdb 6.4-debian
>Description:
On certain calls to fork(), execvp(), gdb does the following:
  thread_db_get_info: cannot get thread info: generic error
after that it is unusable.

This is difficult to replicate in the general case, though I have seen it happen several times with the wxWidgets library using the ::wxExecute() function. I have finally got it 100% repeatable (of course, on the function I want to debug...).

Sadly it is /not/ repeatable using the minimal wxWidgets sample application for exec.
>How-To-Repeat:
Download sources to Xara LX (see http://www.xaraxtreme.org/). You will need at least revision r1463. Build a debug version. Run it under gdb. Draw any shape. File->Export. Browse for other folders, select "MIFF File". Chose any file name ending in ".miff" and OK the default options.

At imgmgkft.cpp line 1313 it calls ::wxExecute to run "convert" (ImageMagick). This does a fork() and an execvp(). 100% reliably, gdb suffers the above internal error.

I don't believe there is anything special about ImageMagick - I've seen similar things happen using the print setup dialog (which runs lp commands), but not reliably.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: