RFC: releasing version 0.1
jones.chris.g at gmail.com
Wed Sep 18 12:53:44 PDT 2013
tl;dr questions for Moz developers:
1. Is it simple / common to hack gecko 27 with multiprocess disabled?
2. Given (1), what's the value of multiprocess support in rr for 0.1
(i.e., the near future)?
Testing with Firefox 27.0a, an unfortunate issue (for rr; it's very
fortunate for FF!) has arisen: some form of multi-process operation is
enabled. (I think I remember hearing this was for tab previews or
something?) This is a problem for two reasons. First, gecko
multiprocessing requires |exec()|ing, but the configuration needed to
install the seccomp-bpf explicitly disables |exec()|. Well, it's supposed
to; exec() succeeds in my x86-64 VM, which is an apparent kernel bug I ran
into before, that doesn't exist on x86. That all means that for FF 27
running on Ubuntu 12.04
1. x86 build on x86-64 kernel: seccomp-bpf works for now, because of
2. x86 build on x86 kernel: seccomp-bpf broken (need to verify, but 99.9%
3. x86-64 build on x86-64: seccomp-bpf would be broken, if rr could
That sucks because the whole point of the 0.1 release was to get
seccomp-bpf working for faster recording. We can wiggle around this
restriction, but it won't be quick or pretty.
The second problem is debugging multiple processes. The rr core (should)
work just fine with multiple processes, because rr doesn't have any concept
of what those are. The problematic code is the gdb interface. It was
designed assuming single-process debugging, for a variety of reasons,
including the fact that gdb support for multiprocess has historically been
poor. AFAICT, the 7.4 build in my VM doesn't support multiple processes in
a way that's useful with rr. I'll try a bit of poking around though.
(You'll note I'm discussing Ubuntu 12.04, which was the original target OS
because it's LTS. I'll also try investigating some newer versions.)
So all this leads up to questions above. My guess is that it's probably
reasonable simple and common to disable multiprocess, and my guess is that
given that, we should forge on with 0.1 as originally planned.
On Tue, Sep 17, 2013 at 4:16 PM, Chris Jones <jones.chris.g at gmail.com>wrote:
> If you've happened to glance at the 0.1 milestone lately, you'll see
> that we should be done with the "release blockers" today or tomorrow.
> After that we'll take a few days trying to squeeze in some easy and
> non-risky performance improvements. Finally, we'll do some last-minute QA
> on more realistic development scenarios and fix the important bugs that
> shake out of there. If all goes well, we're probably looking at a release
> around October 1st.
> So: if you know of an issue that should block the 0.1 release, now is the
> time to file it! :) Note: the "motif" for the 0.1 release is that it's
> reasonably fast and stable on common scenarios; it's worth trying out, but
> no guarantees it'll be super useful. This isn't the "big-splash" release,
> so the bar for blocking is fairly high, IMHO.
>  https://github.com/mozilla/rr/issues?milestone=3&state=open
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rr-dev