Closed Bug 1154445 Opened 8 years ago Closed 8 years ago

[Camera] Crash while stability testing, maybe in camera


(Core :: DOM: Core & HTML, defect)

Gonk (Firefox OS)
Not set



blocking-b2g 2.2+


(Reporter: ggrisco, Unassigned)



(Keywords: crash, Whiteboard: [b2g-crash][caf-crash 475][caf priority: p1][CR 822154])

Crash Data


(10 files)

Saw the folloowing crash signature while running stability test:

[@ xpcObjectHelper::xpcObjectHelper | mozilla::dom::WrapNativeISupportsParent | mozilla::dom::PromiseBinding::Wrap | mozilla::dom::quota::QuotaManager::AbortCloseStoragesForProcess ]

From the logs, looks like camera was being used at time of crash.  cafbot will upload the logs.
Whiteboard: [CR 822154]
Whiteboard: [CR 822154] → [caf priority: p1][CR 822154]
Whiteboard: [caf priority: p1][CR 822154] → [b2g-crash][caf-crash 475][caf priority: p1][CR 822154]
Keywords: crash
Looks like this starts here:

It looks like that particular line has been in the tree for a while. Dave, do you know anything about the QuotaManager? Any idea what might be going on here?
Flags: needinfo?(dhylands)
blocking-b2g: 2.2? → 2.2+
Hi! Becker,

Please also help to take a look. Thanks

Flags: needinfo?(behsieh)
See Also: → 1152407
Component: Gaia::Camera → Stability
Summary: Crash while stability testing, maybe in camera → [Camera] Crash while stability testing, maybe in camera
I'm not familiar with the QuotaManager, but it looks like ContentParent::ShutDownProcess calls it explicitly:

Because this is failing during a stability test, I'm going to guess that there is some type of race happening where the quota manage is trying to close a storage that hasn't been completely opened or something like that.
Flags: needinfo?(dhylands)
I can not comment whether it was relative to camera from such limited information.
in current log from attached,I didn't see any camera error.
is this easy to reproduce.?
is it possible we can set environment here to reproduce this issue?
Flags: needinfo?(behsieh)
is this easy to reproduce.?
is it possible we can set environment here to reproduce this issue?
Flags: needinfo?(ggrisco)
(In reply to becker hsieh{:behsieh} from comment #11)
> is this easy to reproduce.?
> is it possible we can set environment here to reproduce this issue?

This crash was found with monkey test and has only been seen once or twice so far, so it seems difficult to reproduce.
Flags: needinfo?(ggrisco)
is it possible we could set the same environment with you to reproduce this issue?
Flags: needinfo?(ggrisco)
To reproduce the environment you would need to setup some monkey test and run overnight/weekend.  So far we've only seen this crash on AU 129 (it did not reproduce on AU 132).  Maybe if it reproduces on next build we'll have more information to go on.
Flags: needinfo?(ggrisco)

Is this issue due to the same root cause as bug 1152407?

Flags: needinfo?(Jan.Varga)
This has become one of the top hitters affecting mtbf stability numbers.
Flags: needinfo?(mlee)
Please confirm if this issue has the same root cause and solution as bug 1152407. If so can we mark this as a duplicate of it?

If this issue has a different root cause than bug 1152407 which Jan is working on, please have someone else on the DOM team look into this.

As you can see from CAF's (Greg) comment 25, this issue is significantly impacting reaching fxOS 2.2 MTBF goals.

Component: Stability → DOM
Flags: needinfo?(mlee) → needinfo?(overholt)
Product: Firefox OS → Core
I think it's the same root cause.
Flags: needinfo?(Jan.Varga)
Thanks Jan. Marking as a duplicate of bug 1152407 per comment 27.
Closed: 8 years ago
Flags: needinfo?(overholt)
Resolution: --- → DUPLICATE
No longer blocks: CAF-v2.2-metabug
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.