RFC: releasing version 0.1

Robert O'Callahan robert at ocallahan.org
Wed Sep 18 19:13:10 PDT 2013


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.

​That was my understanding too, but I ran a little test program to confirm
> and rr tracees *do* seem to be able to exec().  ​Looking back over
>
> https://github.com/mozilla/rr/pull/253
>
> I see that the filter prog we previously installed to probe support was |ALLOW_PROCESS|.
>  The one rr installs, of course, will |TRACE_PROCESS| for the exec call.
>  That doesn't explain why the probing worked for one kernel and the not the
> other.  But maybe allowing the exec() if it's examined by the tracer is by
> design, that bypasses some kind of check.
>

OK that's good news.


>
>
>> Does this mean we can work around the problem by giving rr CAP_SYS_ADMIN?
>>
>
> ​Maybe, but *shiver* --- the entire FF process tree would need to run as
> root.​
>

That's kinda bad, but not too bad. You can box everything into a VM. Also
IIUC you only need to be root in the relevant user namespace, so it might
be possible to configure a Linux container setup so you can do everything
as non-root.


> 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!


>
>> 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.

My long term plans do not involve gdb anyway.

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/20130919/6769aed4/attachment-0001.html>


More information about the rr-dev mailing list