concurrent rr record sessions on the same binary

Wade Hennessey wadehennessey at gmail.com
Mon Nov 16 07:23:22 UTC 2015


I agree.

I guess you are  saying Mozilla doesn't have rr record failure test farms
running. With the record -c option your scheduler should have less
nondeterminism. . I've run -c 2 to try to reproduce. problems. This finds
my problem , but takes over a day to reproduce. That's too long for
practical debugging since the replay takes a few days, and so far I haven't
gotten checkpoints to work.

Sorry for all this trouble. It's clear that Firefox doesn't have the level
concurrency that I'm trying to debug, and that's your main goal. I still
love the idea. It just may not work for my situation at the moment. -wade

On Sun, Nov 15, 2015 at 10:19 PM, Robert O'Callahan <robert at ocallahan.org>
wrote:

> On Mon, Nov 16, 2015 at 4:58 PM, Wade Hennessey <wadehennessey at gmail.com>
> wrote:
>
>> 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
>>
>
> Doing more test runs should always help, if the scheduler admits a
> sufficient amount of nondeterminism. But we're not nearly there yet.
>
> 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/20151115/b88acb44/attachment.html>


More information about the rr-dev mailing list