Closed
Bug 1274826
Opened 8 years ago
Closed 8 years ago
apps are constantly crashing
Categories
(Firefox OS Graveyard :: Gaia, defect)
Tracking
(firefox49 fixed)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox49 | --- | fixed |
People
(Reporter: jovan.gerodetti, Assigned: gerard-majax)
References
Details
(Whiteboard: fixed-in-pine)
Attachments
(4 files, 1 obsolete file)
With my build from today every app crashes instantly. The homescreen is constantly restarting. Gaia: 0f0db431054adad34c9f402d3e22ab7f54975a44 Gecko: 298617:88534aee6c1b
Reporter | ||
Updated•8 years ago
|
Summary: apps a constantly crashing → apps are constantly crashing
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(fabrice)
I see roughly the same thing on a Nexus 4 build I have just completed. Gaia: 2c0e66f09a6f12219bb13e806ca4ba4a30eae74e (kanikani) Gecko: 298617:88534aee6c1b (pine)
Assignee | ||
Comment 3•8 years ago
|
||
And I don't reproduce on desktop/mulet even after forcing OOP ?
Assignee | ||
Comment 4•8 years ago
|
||
Assignee | ||
Comment 5•8 years ago
|
||
(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 :/
Assignee | ||
Comment 6•8 years ago
|
||
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.
Assignee | ||
Comment 7•8 years ago
|
||
I can confirm with MOZ_NUWA_PROCESS disabled the issue is still happening :/
Assignee | ||
Comment 8•8 years ago
|
||
Logcat with NUWA disabled and B2G_DEBUG=1
Assignee | ||
Comment 9•8 years ago
|
||
So when I disable the sandbox (--disable-sandbox --disable-content-sandbox) then I have no more error ! This gives us some string to pull :)
Assignee | ||
Comment 11•8 years ago
|
||
local revert of bug 1176099 and I do not reproduce the issue anymore!
Blocks: 1176099
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(reuben.bmo)
Flags: needinfo?(gsvelto)
Flags: needinfo?(fabrice)
Assignee | ||
Comment 12•8 years ago
|
||
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?
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(julian.r.hector)
Flags: needinfo?(jld)
Assignee | ||
Comment 13•8 years ago
|
||
fact: if I ifdef exclude sigprocmask(), no problem.
Assignee | ||
Comment 14•8 years ago
|
||
Looks like we do not get a function out of dlsym(). Man shows that RTLD_NEXT is only available when built with _GNU_SOURCE.
Assignee | ||
Comment 15•8 years ago
|
||
Maybe RTLD_NEXT is bugged on bionic (on ours?). Anyway, dlsym() against a handle from a dlopen("libc.so") and it works.
Flags: needinfo?(julian.r.hector)
Flags: needinfo?(jld)
Assignee | ||
Comment 16•8 years ago
|
||
MozReview-Commit-ID: AegVwuPx4uU
Assignee | ||
Comment 17•8 years ago
|
||
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?
Attachment #8756447 -
Flags: feedback?(julian.r.hector)
Attachment #8756447 -
Flags: feedback?(jld)
Comment 18•8 years ago
|
||
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.
Assignee | ||
Comment 19•8 years ago
|
||
https://sourceware.org/bugzilla/show_bug.cgi?id=1319
Assignee | ||
Comment 20•8 years ago
|
||
(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 :)
Comment 21•8 years ago
|
||
I agree with Jed, the code isn't required on B2G, so not building it seems like the better option.
Assignee | ||
Comment 22•8 years ago
|
||
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)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → lissyx+mozillians
Assignee | ||
Updated•8 years ago
|
Attachment #8756447 -
Attachment is obsolete: true
Attachment #8756447 -
Flags: feedback?(julian.r.hector)
Attachment #8756447 -
Flags: feedback?(jld)
Comment 23•8 years ago
|
||
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+
Assignee | ||
Updated•8 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 25•8 years ago
|
||
https://hg.mozilla.org/projects/pine/rev/69fee7f7624a
Whiteboard: fixed-in-pine
Comment 26•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/1743abeb2352
You need to log in
before you can comment on or make changes to this bug.
Description
•