[patch] Use TD_DEATH and PTRACE_EVENT_CLONE when available

Jeff Johnston jjohnstn@redhat.com
Fri Mar 26 18:14:00 GMT 2004


Daniel Jacobowitz wrote:
> On Thu, Mar 25, 2004 at 03:22:13PM -0500, Jeff Johnston wrote:
> 
>>Daniel Jacobowitz wrote:
>>
>>>On Wed, Mar 24, 2004 at 11:39:50PM -0500, Daniel Jacobowitz wrote:
>>>
>>>
>>>>Do you have any code for PTRACE_EVENT_CLONE yet, or should I put
>>>>something together in the morning to verify whether that's the problem?
>>>
>>>
>>>Here you go.  Again, this patch is obviously not ready to go into GDB,
>>>but I have not been able to make it misbehave yet.  I don't know if all
>>>the bits it needs work right in RHEL3, or if my testing was conclusive.
>>>
>>>The highlights:
>>> - Includes most of the previous patch
>>> - Uses PTRACE_EVENT_CLONE to attach to new threads
>>> - Moves handling of events closer to the waitpid call
>>>
>>>There are some potential races but I haven't hit any of them in
>>>practice.  I suspect that with a heavy fork or vfork load (not clone)
>>>you could produce interesting failure modes.
>>>
>>>Give it a try, please.  If it works I'll clean it up.
>>>
>>
>>Works great.  I was unable to get it to misbehave on RHEL3.  Please go 
>>ahead cleaning it up.
> 
> 
> Here's the final patch. The description of the patch is unchanged from
> the above.  The background, for those who did not read the whole
> discussion: in NPTL, a signal delivered to the process when any thread
> is not attached is likely to terminate the process.  So we need to be
> careful to:
>  - know when threads have exited, so that we can attach to new threads
>    which reuse the same thread ID
>  - attach to threads as early as possible
> 
> Both of these could cause problems in LinuxThreads, but they were less
> drastic.
> 
> Tested with both LinuxThreads and NPTL.  I'll commit this to HEAD on
> Monday, barring objections.  We've missed the boat for GDB 6.1 at this
> point.
> 
> The testcase you posted has credits in it, so we can't just grab it for
> the testsuite.  But all we should need to test this is a loop that
> creates short-lived threads, and then verifying that we can send C-c,
> get a prompt, issue info threads, and continue a couple of times
> without seeing anyting matching "error:".  Interested in writing that
> test? :)
>

Sure.  Just tried debugging eclipse today with this patch applied and it works 
as well.

-- Jeff J.




More information about the Gdb-patches mailing list