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)

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

xref issue #1234

Owner: ---

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

xref issue #1283

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.

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

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

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).

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

xref #3535