concurrent rr record sessions on the same binary
wadehennessey at gmail.com
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 ocallahan.org>
> On Mon, Nov 16, 2015 at 3:47 PM, Wade Hennessey <wadehennessey at gmail.com>
>> 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.
>> 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.
> lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf
> selthor stor edna siewaoeodm or v sstvr esBa kbvted,t
> o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea
> .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rr-dev