Closed Bug 813356 Opened 12 years ago Closed 12 years ago

OS crash with this testcase, that's opening/closing windows


(Firefox OS Graveyard :: General, defect, P1)

Gonk (Firefox OS)


(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed)

blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed
firefox20 --- fixed


(Reporter: martijn.martijn, Assigned: cjones)




(Keywords: crash, testcase)


(1 file)

Steps to reproduce:
- Visit url testcase, tap on the  button

Expected result:
- tab windows open (5 of them), then close

Actual result:
- crash, os reboot
I submitted the FirefoxOS crash reports, with the dialog at the bottom that I'm seeing after the system reboot.
I don't know where you could see those, though. My Otoro phone nr. is 12539.
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
Justin, can you take this one?
Assignee: nobody → justin.lebar+bug
(In reply to Lawrence Mandel [:lmandel] from comment #2)
> Justin, can you take this one?

I'm trying to focus on memory usage.

Patrick, do you think you have time to look at this?
I did some tests about this bug.

1. We can reproduce this bug by just opening 5 windows at once. We don't need to close the 5 windows.

2. The crash occurs at /gfx/layer/Layers.h[1], because the argument of the method is 0x0. The caller WalkTheTree()[2] calls the method with the argument which is stored in a static map (sIndirectLayerTrees). It seems there is some function modified the map before WalkTheTree uses them. But I haven't found when the value is changed.

3. If we make program run slower, like by printing more log or disabling optimization, this bug may not be reproduced. Looks like there's a race condition.

Assignee: justin.lebar+bug → gwright
Setting priority based on triage discussions.  Feel free to decrease priority if you disagree.
Priority: -- → P1
This looks like a crash in layers code, which is pretty weird.  Jeff / Roc, are you willing and able to dig deeper into this?
This crash suggests that the b2g main thread thinks a frame is visible, but we don't have a shadow tree for that frame.  (Or it was destroyed.)

We can fix the crash by null-checking, but that might result in graphical artifacts from not rendering part of what the main thread wants to render.  But better than crashing.
I can't reproduce this with the above testcase, but it's not illegal for a shadow tree to have a null root so we should null-check when resolving.
Assignee: gwright → jones.chris.g
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.