attach handling of signal arriving between handler being instated and takeover

[derekbruening]

From bruen...@google.com on July 29, 2013 18:20:12

For attaching and taking over existing threads, there will always be a race
between installing our signal handler and sending the suspend signal to
each target native thread. We need to handle app signals received in a
native thread during this window.

If delayable, we can queue them up -- if our queue heap is set up.

If an itimer, we could just drop the signal.

If un-delayable, we may need to copy to the app's signal stack and
implement a go-native path to the app handler.

Xref issue #26 , issue #359 , issue #777 , which I believe cover different time windows
(pre-dcontext-setup).

Xref loosely related issue #150 .

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1234

[derekbruening]

From bruen...@google.com on August 05, 2013 10:14:15

xref issue #1242

[derekbruening]

From p...@google.com on August 05, 2013 10:40:00

What is the actual race condition? E.g. are there some steps that cannot be performed atomically (e.g. changing FS/GS base, calling sigaction) that, if a signal arrives in-between, result in inconsistent state?

[derekbruening]

From bruen...@google.com on August 05, 2013 12:58:54

We need to install our signal handler before we send the suspend signal to each thread. So we have to first call sigaction and then loop through the threads and send each one a signal. Some other signal can arrive between the sigaction and the arrival of our suspend signal. If it arrives, we haven't yet initialized that thread. (In addition to the above actions, an alternative could be to initialize on any signal and wait for the resume -- though it's perhaps not so different from queuing it.) In practice, in our code the sigaction and the send of the suspend signal are separated by quite a bit of initialization code, IIRC.