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

Status: RESOLVED FIXED

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

Description

[Martijn Wargers (dead)]

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

Comment 1

[Martijn Wargers (dead)]

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.

Comment 2

[Lawrence Mandel [:lmandel] (use needinfo)]

Justin, can you take this one?

Comment 3

[Justin Lebar (not reading bugmail)]

(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?

Comment 4

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

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.


[1] https://mxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.h?rev=cf8750abee06#1593
[2] https://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/CompositorParent.cpp?rev=a79d36c9174b#485

Comment 5

[Andrew Overholt [:overholt]]

Setting priority based on triage discussions.  Feel free to decrease priority if you disagree.

Comment 6

[Justin Lebar (not reading bugmail)]

This looks like a crash in layers code, which is pretty weird.  Jeff / Roc, are you willing and able to dig deeper into this?

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Skip subtrees with null roots during resolution

Comment 10

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0251c6a43055

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0251c6a43055

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/1429cead644b
https://hg.mozilla.org/releases/mozilla-beta/rev/b78e06daaad0