Externally-triggered detach auto-restart syscall skipping not working

[egrimley-arm]

If the main thread is in a futex system call (for example in pthread_join) or in a wait4 system call (for example in wait) then detach has no effect: it seems that DynamoRIO's signal handler is run but no other action is taken because the signal handler returns to the system call and the dispatch loop is never entered.

If the main thread is in a read system call then detach does not take effect until the system call returns.

If the main thread is in a clock_nanosleep system call (for example in sleep) then detach causes the system call to return prematurely.

However, detach works properly if the main thread is in an infinite loop with no system calls.

(This may be the reason for it not being possible to detach from some "real-life" multi-threaded applications.)

(All of this was tested on AArch64.)

[derekbruening]

Attaching in the middle of an auto-restart syscall is a known issue that had multiple solutions in the original ptrace attach support: see the original PR #5019 which talks about waiting via single-stepping as the default, with a return option under -skip_syscall. We later made -skip_syscall the default in PR #5462: even though it's not perfectly transparent it seemed the most practical solution.

Supposedly -skip_syscall worked on AArch64 in PR #5460 so has there been a regression since then, or was the test there not sufficient?

[egrimley-arm]

Until this is fixed properly there seems to be a work-around: you can invoke drconfig -detach $TID with the TID of a thread that isn't in a blocking system call, which may be any thread other than the main thread, or you could use top -H to find a thread that is using CPU.