RFC: releasing version 0.1
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)
> 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
> 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
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
> 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.
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...
More information about the rr-dev