Closed Bug 1274826 Opened 8 years ago Closed 8 years ago

apps are constantly crashing

Categories

(Firefox OS Graveyard :: Gaia, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

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)

Attached file adb logcat output
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
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)
And I don't reproduce on desktop/mulet even after forcing OOP ?
Blocks: 1252143
(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 :/
Attached file no_nuwa_debug.log
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
Flags: needinfo?(reuben.bmo)
Flags: needinfo?(gsvelto)
local revert of bug 1176099 and I do not reproduce the issue anymore!
Blocks: 1176099
Flags: needinfo?(reuben.bmo)
Flags: needinfo?(gsvelto)
Flags: needinfo?(fabrice)
Blocks: 1275603
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?
Flags: needinfo?(julian.r.hector)
Flags: needinfo?(jld)
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.
Flags: needinfo?(julian.r.hector)
Flags: needinfo?(jld)
MozReview-Commit-ID: AegVwuPx4uU
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)
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.
Assignee: nobody → lissyx+mozillians
Attachment #8756447 - Attachment is obsolete: true
Attachment #8756447 - Flags: feedback?(julian.r.hector)
Attachment #8756447 - Flags: feedback?(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
https://hg.mozilla.org/projects/pine/rev/69fee7f7624a
Whiteboard: fixed-in-pine
https://hg.mozilla.org/mozilla-central/rev/1743abeb2352
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: