RFC: releasing version 0.1

Chris Jones jones.chris.g at gmail.com
Wed Sep 18 21:15:51 PDT 2013

(Apologies for missed reply-all, I'm just out of practice ;) .)

On Wed, Sep 18, 2013 at 7:13 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Thu, Sep 19, 2013 at 12:12 PM, Chris Jones <jones.chris.g at gmail.com>wrote:
>> ​Right.  The question I was trying to ask is, there's a universe U = S ∪
>> M​ of bugs rr can help with, where S are the single-process ones and M
>> multiprocess.  There's a utility to Moz devs for both S and M.  There's an
>> rr cost to adding multiprocess support.  Unfortunately, while multi-process
>> support is enabled in FF and not fully supported in rr, there's also an
>> opportunity cost to Moz devs on missed utility(S).  But there's also a cost
>> to Moz devs in disabling multiprocess when using rr.  ​So the relevant data
>> to making a decision wrt Moz devs are​
>>  utility(S) cmp utility(M)
>> ​ ​cost(disabling-multiprocess)
>> ​Like I said, my guess is that (i) utility(S) > utility(M); (ii)
>> cost(disabling-multiprocess) << utility(S), so it probably makes sense to
>> go forward with the original 0.1 plan.  I would love to have that
>> confirmed, and I think you did below.
> Yes, I agree.
> My highest priority for utilizing rr is still nondeterministic test
> failures, and they mostly don't require multiprocess at this point.

​Cool, that's what I had in mind.​

I guess as a last resort, or if we moved seccomp-bpf support back to
>> opt-in.  Fwiw, my thought was to keep a non-filtered "template" process and
>> fork that when needed, plus emulating whatever we need of the POSIX
>> parent-process API.  Fingers crossed about TRACE'ing the exec() calls
>> though! :)
> I believe it's also possible to fully emulate exec(), although it would
> really suck to have to implement that!

​*shiver* *shiver* :)​

>>> Would it be easy to provide a way to select which process gets debugged?
>>> That would be more than enough for now, I think. But your followup seems to
>>> suggest this would not be easy?
>> ​We don't currently have a way.  gdb doesn't tell which rr which
>> executable image it loaded.  ​If there were a way to query that information
>> from gdb (I didn't find one, as silly as that sounds), then we could (i)
>> add code to track which tasks are in which address spaces (easy); (ii)
>> "hide" tasks from gdb that don't match the executable image under debugging
>> (relatively easy).
> If we can do those two things, why don't we just ask the user to pass a
> PID to rr replay, and enable debugging for just that PID? Making the user
> jump through a hoop here is not a problem.

​I guess.  Once we have the filtering in place the UI is just, well, UI.
 One thing that came to mind was popping up a "debug this fork() child?
[yn]" dialog each time we see an exec() or fork() that matches the spec.
 But not a big deal either way.

> My long term plans do not involve gdb anyway.

​Right, I just thought it would have gotten us further in the short term
:/.  But we'll see how things look in newer OSes.


> R
> --
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
> waanndt  wyeonut  thoo mken.o w  *
> *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20130918/78bd4430/attachment.html>

More information about the rr-dev mailing list