<div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace">tl;dr questions for Moz developers:</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div>
<div class="gmail_default" style="font-family:'courier new',monospace"> 1. Is it simple / common to hack gecko 27 with multiprocess disabled?</div><div class="gmail_default" style="font-family:'courier new',monospace">
 2. Given (1), what's the value of multiprocess support in rr for 0.1 (i.e., the near future)?</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">
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</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">  1. x86 build on x86-64 kernel: seccomp-bpf works for now, because of kernel bug</div>
<div class="gmail_default" style="font-family:'courier new',monospace">  2. x86 build on x86 kernel: seccomp-bpf broken (need to verify, but 99.9% sure)</div><div class="gmail_default" style="font-family:'courier new',monospace">
  3. x86-64 build on x86-64: seccomp-bpf would be broken, if rr could record x86-64</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">
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.<br></div><div class="gmail_default" style="font-family:'courier new',monospace">
<br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.<br>
</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">(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.)</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">lmk</div><div class="gmail_default" style="font-family:'courier new',monospace">
<br></div><div class="gmail_default" style="font-family:'courier new',monospace">Cheers,</div><div class="gmail_default" style="font-family:'courier new',monospace">Chris</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Sep 17, 2013 at 4:16 PM, Chris Jones <span dir="ltr"><<a href="mailto:jones.chris.g@gmail.com" target="_blank">jones.chris.g@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace">Howdy,</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">

If you've happened to glance at the 0.1 milestone[1] 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.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Cheers,</div><div class="gmail_default" style="font-family:'courier new',monospace">

Chris</div><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">[1] <a href="https://github.com/mozilla/rr/issues?milestone=3&state=open" target="_blank">https://github.com/mozilla/rr/issues?milestone=3&state=open</a></div>

</div>
</blockquote></div><br></div>