[Bug testsuite/31312] attach-many-short-lived-threads gives inconsistent results

["pedro at palves dot net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31312

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pedro at palves dot net

--- Comment #27 from Pedro Alves <pedro at palves dot net> ---
> I did reach out to the kernel community about this.  There are some timing issues 
> that can cause the kernel to legitimately return EPERM.  He pointed me to the ptrace 
> Linux man page.  Another possible cause for the EPERM is if ptrace is already 
> connected to the process.  I tried to determine if this was in fact the case.  
> Specifically if the detach hadn't completed yet but was not able to show that was the 
> failure case.  

I'm not convinced the kernel folks understood the issue completely.  The ptrace
man page doesn't talk about timing issues wrt EPERM.  Also, if the attach fails
with EPERM due to a timing issue, then sleeping a while and then trying again
should succeed, but that is not what you observed, IIUC.

> The gdb log says that it detached from the pid.  I don't find any way to verify that.  
> I don't see any gdb attached thread status command that would verify it. 

There isn't one.  You can however look at /proc/PID/status, check the State:,
and the TracerPid: lines.  TracerPid in particular, as it tells you the pid of
the ptracer, which should be either "0" is not being traced (debugged), or
GDB's pid.

-- 
You are receiving this mail because:
You are on the CC list for the bug.