Closed Bug 1054208 Opened 6 years ago Closed 6 years ago

B2G process assertion failure at ParticularProcessPriorityManager::SetPriorityNow() when there's an incoming call

Categories

(Core :: DOM: Content Processes, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla34

People

(Reporter: ting, Assigned: ting)

Details

Attachments

(3 files, 1 obsolete file)

Attached file backtrace
I ran into this issue while trying repro bug 1054011.

STR:
1. Use more fingers (I used three) to tap application icons fast randomly on Homescreen to launch them simutaneously
2. Hit assertion (http://dxr.mozilla.org/mozilla-central/source/dom/ipc/ProcessPriorityManager.cpp#1044) and B2G restarts, see attached backtrace

Repro rate:
~1/5

Version:
34.0a1
gecko = 0ec002deb3134e52ca13bf3081d775f06ee3b62f
gaia = 80039d982f5a1befc1aae7cfb8609ea88da1528a

Config:
export MOZ_PROFILING=1
export ENABLE_MARIONETTE=1
export B2G_DEBUG=1
Nasty, this looks like a race, moving to the right component.
Component: General → IPC
Product: Firefox OS → Core
OS: Linux → Gonk (Firefox OS)
Component: IPC → DOM: Content Processes
(In reply to Ting-Yu Chou [:ting] from comment #0)
> 2. Hit assertion
> (http://dxr.mozilla.org/mozilla-central/source/dom/ipc/
> ProcessPriorityManager.cpp#1044) and B2G restarts, see attached backtrace

The assertion in ParticularProcessPriorityManager::SetPriorityNow() to make sure aPriority != PROCESS_PRIORITY_UNKNOWN.
(In reply to Ting-Yu Chou [:ting] from comment #2)
> The assertion in ParticularProcessPriorityManager::SetPriorityNow() to make
> sure aPriority != PROCESS_PRIORITY_UNKNOWN.

Yes, I wonder if this is triggered by the same race that sometimes gets us two preallocated processes, see bug 1051745.
I hit the same assertion when there's an incoming call, repro rate 5/5.

Version:
34.0a1
gecko = 3bf1a97537d3651304bb158e5cd9a500d9dcb846
gaia = 52ba2a04bf0130f594237ec78eac3a002d4c6203
Summary: B2G process assertion failure at gecko/dom/ipc/ProcessPriorityManager.cpp:1044 → B2G process assertion failure at ParticularProcessPriorityManager::SetPriorityNow() when there's an incoming call
Version: unspecified → Trunk
I'll check this.
Assignee: nobody → tchou
ParticularProcessPriorityManager of Nuwa always has |mPriority| -1, since |SetPriorityNow| returns if the content parent is Nuwa process. Whenever iterate |pppms| to call |ResetCPUPriorityNow|, -1 will be used for it and hit the assertion.
Attached patch patch (obsolete) — Splinter Review
Don't assert the input for Nuwa as we ignore it.
Attachment #8480401 - Flags: review?(gsvelto)
Comment on attachment 8480401 [details] [diff] [review]
patch

Review of attachment 8480401 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me, thanks for looking into this.
Attachment #8480401 - Flags: review?(gsvelto) → review+
Attached patch patchSplinter Review
Add r=gsvelto.
Attachment #8480401 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/2074e9320edd
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.