handle pre-thread-init and post-exit signals

[derekbruening]

From derek.br...@gmail.com on February 18, 2009 14:38:22

with NPTL (POSIX) a SYS_kill signal is delivered to a single thread chosen arbitrarily among those that aren't blocking it (each thread has its own signal mask). this means a thread can receive a signal during our thread initialization, before we've set up its dcontext and other structures, in which case we die.

we also have problems when a signal comes in during process exit after we've removed our handler: the app then dies ungracefully. technically that could happen natively too but is much less likely since it exits more quickly. this is less of an issue for release build and is more of an annoyance for itimer testing.

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

[derekbruening]

From rnk@google.com on May 18, 2012 13:03:04

This is a meta issue for coming up with a bulletproof solution to this problem.

We've encountered specific instances of this bug in: issue #359 (alarm signals in thread init) issue #777 (using sigaltstack after free)

[derekbruening]

From bruen...@google.com on July 29, 2013 15:20:28

xref issue #1234

Owner: ---

[derekbruening]

From bruen...@google.com on October 05, 2013 09:14:37

xref issue #1283

[derekbruening]

I'm lumping the corner cases from #2161 and #2270, signals arriving during attach and detach, into this issue. We now ignore the 3 classic alarm signals, but other signals can be sent to the whole process, and timer_create lets unusual signals be used as timers.

[derekbruening]

This was hit on Travis: https://travis-ci.org/DynamoRIO/dynamorio/jobs/345514707

 95/289 Test  #90: code_api|pthreads.ptsig ......................................***Failed  Required regular expression not found.Regex=[^Estimation of pi is 3\.142425985001098
$
]  0.52 sec
<ERROR: master_signal_handler with no siginfo (i#26?): tid=21118, sig=10>
Estimation of pi is 3.142425985001098

[derekbruening]

b4da8d159 put in a release-build message for this: Cannot correctly handle a received signal.

[derekbruening]

From a discussion about handling signals in threads with no dcontext:

During detach, a thread that has already gone native could receive a signal while DR's handler is still in place because it's sending the other threads native and cleaning up.

It could be a synchronous signal via some fault or trap in the native code it's running or an asynchronous signal sent from another thread or process

The signal frame is already on the right stack b/c the thread's signal state is already native. If we can find the app's signal handler we could just change the PC to that handler (and also fix up the in-handler mask and any other differences between the handlers). For SIG_IGN we can just issue sigreturn; for SIG_DFL we have the same issues full DR has for how to emulate.

For finding the app's signal handler: we could search the all_threads table, but detach is going on simultaneously and it may be freed underneath us. For simple cases of a single process-wide handler we could store the app handler globally or sthg. We would not handle the native thread changing the handler: but neither does detach in general (it would need a barrier and wait for all threads to be ready for native before releasing them which seems like a performance problem for many-threaded apps).

[derekbruening]

For a thread exiting (non-detach) the proposal is just to block all signals at the start of DR's thread exit.

[hgreving2304]

xref #3535