Closed Bug 852251 Opened 11 years ago Closed 11 years ago

Multiple crashes seen in "layers" while on call and attempting FTP over DUN

Categories

(Core :: Graphics: Layers, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla23
blocking-b2g tef+
Tracking Status
firefox21 --- wontfix
firefox22 --- wontfix
firefox23 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- fixed

People

(Reporter: ggrisco, Assigned: ajones)

Details

(Keywords: crash, Whiteboard: [b2g-crash][CR 462595])

Crash Data

Attachments

(3 files)

Breaking up bug 848003 into individual reports


1. Make MO call using QXDM
2. Make Dialup Networking (DUN) call and start FTP download test case

After the weekend run, device collected many minidumps.  Minidump attached.
blocking-b2g: --- → tef?
Attached file EXTRA file attachment
Crash Signature: [@ mozilla::layers::PCompositorChild::SendPLayersConstructor ]
Keywords: crash
(tef+ due to regression in stability)
blocking-b2g: tef? → tef+
What's the "FTP download case"?  Is that downloading a file in the browser using FTP, or an system-level app update?   I'm afraid I also don't know what a "MO call using QXDM" is.  (I'm just trying to get a sense for 1) how common the use case is here and 2) how the parts interact and 3) a clear set of STR so we can debug).

From the stack trace, I'm not clear on how the FTP download could be triggering this.  The crash stack is all Layers code (crashing at PCompositorChild::SendPLayersConstructor).  And on the child, FTP only operates on the main thread, and none of the FTP code is on the main thread stack in this crash.  But of course earlier FTP events on the main thread might be changing state somehow to cause this.  But I suspect the brokenness is all up above the FTP code itself.

Assigning to Jeff just because he seems to be the (latest) person to take the other Layers IPDL bug (bug 851664).
Assignee: nobody → jmuizelaar
Component: General → Graphics: Layers
Product: Boot2Gecko → Core
I'm not sure how actionable this is without being able to reproduce this locally.
Flags: needinfo?(ggrisco)
Please try to look at the backtrace and attempt to determine how this could happen.  Reproducing these types of issues locally can be difficult and an time-consuming due to test setup.   The "FTP download case" stuff is the name of the stability test that cause this crash to occur /somehow/, but obviously the crash has nothing to do with FTP.  We just got (un)lucky and hit this layers bug as a part of that test.
Clearing my ni since I can't provide more clear STR.  This has been reproduced in last two AUs that we ran stabiilty tests on.
Flags: needinfo?(ggrisco)
Anthony or Nick, can one of you take a look?
Flags: needinfo?(ajones)
It looks like CompositorChild::Get() may be returning a null. That would happen if it is called before CompositorChild::Create() or after CompositorChild::Destroy(). There is no null check in TabChild::InitRenderingState(). Something is happening out of order but without a way to reproduce the problem all I can do is put in a null check in InitRederingState().
Flags: needinfo?(ajones)
I got nothing, sorry
Anthony asked me to see if I've got something here, but I need to run now.
Flags: needinfo?(justin.lebar+bug)
Assignee: jmuizelaar → ajones
I think this patch is probably right, based on the comment in TabChild::RecvShow.

Anyway it seems difficult to imagine how this patch would make things worse than they already are.
Flags: needinfo?(justin.lebar+bug)
Comment on attachment 729829 [details] [diff] [review]
Check for null on CompositorChild::Get()

r=me
Attachment #729829 - Flags: review+
is this ready to land? thanks
https://hg.mozilla.org/mozilla-central/rev/9ecc1799f6f4
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: