Comment 1 by tom.fogal:

burns.ethan@gmail.com suggested that I add:
  func init() { runtime.LockOSThread() }
to the program.  This does indeed seem to fix the problem!
The 'SysProcAttr'ibutes includes (as used in the program above) an attribute to indicate
that one wants to trace the spawned process.  It seems from this example that the
default setup, however, will never work without locking the thread.  Perhaps
forkAndExecInChild should lock the thread for the user, then?

Comment 2:

I haven't tried to figure out what is going on here, but given that we have a Ptrace
field in syscall.SysProcAttr we should document this or fix it.

Labels changed: added repo-main, release-go1.3maybe.

Comment 3:

All calls to ptrace for a given child must be made from the same thread. It's a ptrace
API bug that no Unix vendor has bothered to fix. There are many such problems with
ptrace. I am not sure we can document them all, or even in enough detail to explain how
to use it. Syscall in particular is mostly undocumented. Perhaps some day operating
systems will have a good API for debugging programs.

Status changed to Unfortunate.

Unfortunate indeed, I just wasted many days of project progress on this bug. 😿

I was intercepting syscalls using ptrace's syscall.PtraceSyscall and I was getting syscall.ESRCH, but only intermittently after 30k to 200k successful interception enter-exit cycles.

I think either:

1. We should add syscall package documentation line that reads "All calls to ptrace for a given child must be made from the same thread; therefore, use runtime.LockOSThread() to guarantee this behavior occurs for any programs that use syscall.Ptrace*(.. functions".
2. We should call runtime.LockOSThread() the first time a `syscall.Ptrace* function is used and document that behavior in the syscall package.

I realize this is a stupid (non-Go) API fragility, but the current Go API inferface implementation is both guaranteed to break by default for non-trivial ptrace use cases and, while known to be so, is not documented to say so. Perhaps this was less of a major issue back at 1.3 when GOMAXPROCs defaulted to 1?

@rsc @ianlancetaylor Does this need to be re-evaluated in light of the GOMAXPROCs change that took place with Go 1.5?

This is unrelated to GOMAXPROCS.

...that is, even with GOMAXPROCS 1, Go has always used different threads.

...that is, even with GOMAXPROCS 1, Go has always used different threads.

OK, thanks for the clarification, I wasn't sure if that was the case. I still think something should be done, even if its a single sentence of documentation. That of course is just an opinion.

Two year old issues are not the place for this, though. This bug is already fixed. In fact, we're about to deploy a bot to auto-freeze all old closed issues. Please open a new one for documentation.