RFC: releasing version 0.1

Robert O'Callahan robert at ocallahan.org
Wed Sep 18 15:33:31 PDT 2013


On Thu, Sep 19, 2013 at 7:53 AM, Chris Jones <jones.chris.g at gmail.com>wrote:

>  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)?
>

1. On trunk multiprocess is used by default for generating Web page
thumbnails. Also, there's an increasing number of people doing e10s desktop
work --- who could really benefit from rr.
2. It would be quite valuable.


> 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
> kernel bug
>   2. x86 build on x86 kernel: seccomp-bpf broken (need to verify, but
> 99.9% sure)
>   3. x86-64 build on x86-64: seccomp-bpf would be broken, if rr could
> record x86-64
>

Hmm, I did not know that.

https://groups.google.com/forum/#!topic/linux.kernel/TvZ2EzBtwmA[1-25-false]
"Filter programs may _only_ cross the execve(2) barrier if last filter
program was attached by a task with CAP_SYS_ADMIN capabilities in its
user namespace."
Does this mean we can work around the problem by giving rr CAP_SYS_ADMIN?

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

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?

I think we can ditch this for 0.1 though.

Rob
-- 
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/dc0809fa/attachment.html>


More information about the rr-dev mailing list