Closed Bug 1274826 Opened 3 years ago Closed 3 years ago
apps are constantly crashing
73.04 KB, text/plain
51.77 KB, text/x-log
144.32 KB, text/x-log
58 bytes, text/x-review-board-request
With my build from today every app crashes instantly. The homescreen is constantly restarting. Gaia: 0f0db431054adad34c9f402d3e22ab7f54975a44 Gecko: 298617:88534aee6c1b
Summary: apps a constantly crashing → apps are constantly crashing
I see roughly the same thing on a Nexus 4 build I have just completed. Gaia: 2c0e66f09a6f12219bb13e806ca4ba4a30eae74e (kanikani) Gecko: 298617:88534aee6c1b (pine)
And I don't reproduce on desktop/mulet even after forcing OOP ?
(In reply to Alexandre LISSY :gerard-majax from comment #3) > And I don't reproduce on desktop/mulet even after forcing OOP ? Checking |adb shell b2g-ps| I can see lots of processes spawn/dying, pointing to maybe NUWA broken :/
Given the past buildability state of m-c it's going to be tough to try any bisect for this issue. I am doing a build without NUWA to confirm whether this is because of it or not.
I can confirm with MOZ_NUWA_PROCESS disabled the issue is still happening :/
Logcat with NUWA disabled and B2G_DEBUG=1
So when I disable the sandbox (--disable-sandbox --disable-content-sandbox) then I have no more error ! This gives us some string to pull :)
cf comment 9
Jed, Julian, does it makes any sense to have this SandboxHooks machinery from bug 1176099 on B2G ? And if it makes sense, what are the risks of not making use of it?
fact: if I ifdef exclude sigprocmask(), no problem.
Looks like we do not get a function out of dlsym(). Man shows that RTLD_NEXT is only available when built with _GNU_SOURCE.
Maybe RTLD_NEXT is bugged on bionic (on ours?). Anyway, dlsym() against a handle from a dlopen("libc.so") and it works.
Comment on attachment 8756447 [details] [diff] [review] Force looking into libc.so on Gonk for sandbox hooks r=... So, maybe RTLD_NEXT is broken on bionic, I still need to check this. But in the meantime, here is a patch that should not break desktop and make it working on Gonk. Asking feedback to know if you agree with this approach?
The sigprocmask interception is needed only if there are libraries that create threads that block all signals. We didn't run into any problems with that on B2G, so I think it would make sense to just not build SandboxHooks on B2G.
(In reply to Jed Davis [:jld] [away until 06-01] [⏰MDT; UTC-6] from comment #18) > The sigprocmask interception is needed only if there are libraries that > create threads that block all signals. We didn't run into any problems with > that on B2G, so I think it would make sense to just not build SandboxHooks > on B2G. Sure, tell me whathever you prefer between just not building this on B2G or the patch I submitted :)
I agree with Jed, the code isn't required on B2G, so not building it seems like the better option.
Review commit: https://reviewboard.mozilla.org/r/55278/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/55278/
Attachment #8756611 - Flags: review?(jld)
Comment on attachment 8756611 [details] MozReview Request: Bug 1274826 - Bypass building SandboxHooks on Gonk r?jld https://reviewboard.mozilla.org/r/55278/#review52080
Attachment #8756611 - Flags: review?(jld) → review+
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.