concurrent rr record sessions on the same binary

Wade Hennessey wadehennessey at
Mon Nov 16 03:58:14 UTC 2015

Adding more nondeterminism to the scheduler would definitely help.

There is one other approach I've been thinking of, but I don't see any
mention of it. Has Mozilla come up with a framework for automating rr
record sessions with variations in record options and allowed cpu run time?
The idea is to run lots of concurrent record sessions, possibly over an
indefinite period just trying to find a lucky run that exposes a problem.
It doesn't really matter what the problem is, and whole server farms of
machines could possibly just run rr record sessions searching for test runs
that rarely fail. Maybe Mozilla already does this. It doesn't seem like a
hard problem to address, it's just pretty brute force.-wade

On Sun, Nov 15, 2015 at 6:49 PM, Robert O'Callahan <robert at>

> On Mon, Nov 16, 2015 at 3:47 PM, Wade Hennessey <wadehennessey at>
> wrote:
>> Is it safe to run multiple rr record sessions on a single binary? I
>> assume it is, but I don't want to do it if there are known problems.
> Yes.
>> I have trouble recreating bugs under rr because running everything on one
>> core makes my bugs disappear even after many hours and low max_ticks (-c)
>> settings. -wade
> Yes, that's definitely a problem for some bugs. I'm trying some approaches
> to make this better by introducing more nondeterminism into the scheduler.
> 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: <>

More information about the rr-dev mailing list