large signal-related changes

Robert O'Callahan robert at
Mon Feb 13 01:13:43 UTC 2017

I just pushed some large changes to rr master. The thoughts behind
them are chronicled here:

Previously we had two major problems:
1) We could receive more than one signal during a single call into the
syscallbuf and we'd just keep stashing them. If the handler for the
first signal blocked other signals, this forced us to try to handle a
subsequent signal in a task which perhaps should never have received
2) There were lots of ways we could be in the syscallbuf code, receive
a signal, stash it, and then leave syscallbuf code without delivering
the signal. This includes receiving a signal on the exit path from
`syscall_hook`, and receiving a signal in one of the function
overrides such as `sysconf`. This could mean signal handling not being
performed in a timely manner, and if we go into a blocking syscall
before processing the stashed signal, we might even hang.

Solution to part 1: once one signal has been stashed, block all other
signals until we leave the syscallbuf code. Set breakpoints on syscall
instructions to ensure we don't enter a syscall while all signals are
Solution to part 2: separate syscallbuf-specific code into its own
source file and then identify the code range for the functions in that
file, and do a bunch of tweaks to make sure we never exit syscallbuf
code except via a single identified "syscallbuf exit instruction".
While we have a stashed signal we set a breakpoint on that exit
instruction to ensure we don't leave the syscallbuf with signals
blocked or stashed signals pending.

This passed tests for me but is causing interrmittent failures on
Keno's 'anubis' machine so I'm looking into that now.

lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr  esn

More information about the rr-dev mailing list