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

["Matthew M. DeLoera" <mdeloera at exacq dot com>]

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!