rr, threads, and signal handlers

Wade Hennessey wadehennessey at gmail.com
Tue Nov 3 04:19:59 UTC 2015

So I put an explicit sched_yield() in the busy wait loop and the program
still hangs.

I should be able to produce a small standalone case though. I'll send it to
this list when I have one that reproduces the problem. It's pretty simple.

Thanks for the quick replies. -wade

On Mon, Nov 2, 2015 at 8:02 PM, Robert O'Callahan <robert at ocallahan.org>

> On Tue, Nov 3, 2015 at 4:39 PM, Wade Hennessey <wadehennessey at gmail.com>
> wrote:
>> I don't know if this list is the right place to ask a question about rr,
>> pthreads and signal handlers, but it's the only place I've found.
>> I have a program with 2 threads (but it could be an arbitrary number).
>> Thread one at some point sends a signal to thread 2, and thread 2 has a
>> signal handler that gets called. Thread 2 does a small amount of work and
>> then busy waits for thread 1 to change the state of a global variable to
>> indicate that it's ok to return from the signal handler.
>> This program works fine without rr, but when I run try to rr record it,
>> it hangs, seemingly because thread 1 never gets a chance to run and tell
>> the signal handler on thread 2 that it's ok to return. Does rr require the
>> signal handler on thread 2 to return before allowing thread 1 to run
>> because of an rr limitation (i.e - everything runs on one core and signal
>> handlers must return before any other thread can execute?).
> rr should allow a context switch in that case. I'm not sure why you're
> deadlocking.
> Inserting a sched_yield while busy-waiting should make the problem go
> away. Does it?
> Does the problem show up if you write a small standalone testcase with the
> behavior you described?
> Rob
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20151102/4e46e801/attachment.html>

More information about the rr-dev mailing list