Closed Bug 864598 Opened 11 years ago Closed 11 years ago

Camera app crashes system when switching to camcorder

Categories

(Firefox OS Graveyard :: Gaia::Camera, defect, P1)

Product:
Firefox OS Graveyard
Component:
Gaia::Camera
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(b2g18 unaffected, b2g18-v1.0.1 unaffected)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
b2g18 --- unaffected
b2g18-v1.0.1 --- unaffected

People

(Reporter: diego, Assigned: bjacob)

References

Details

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

Crash Data

Attachments

(1 file, 1 obsolete file)

Camera to camcorder crash stack
3.78 KB, text/plain
Details
Attached file Camera to camcorder crash stack (obsolete) —
Likely caused by the recent layers refactoring
Severity: normal → critical
Priority: -- → P1
Crash also occurs (although I didn't confirm it's the same backtrace) when the camera app is closed via the task switcher.
Assignee: nobody → milan
Crash Signature: [@ mozalloc_abort(char const*) | NS_DebugBreak | mozilla::layers::PGrallocBufferParent::Write()]
Keywords: crash
Whiteboard: [b2g-crash]
Benoit, Snorp, could you take a look at this, Benoit, as a priority?
Assignee: milan → bjacob
I'm already busy with bug 864017, so I can't make concrete promises until I'm done with it. But I'm putting it on my queue.
Updated crash stack with latest from m-c
Attachment #740583 - Attachment is obsolete: true
OK, I've looked at the stack now. This is a known issue and is reproducible in various ways. Yes, it's a regression from layers-refactoring, and is obviously a top priority to fix. Other bugs filed about basically the same crash include bug 853960. The problem is that nobody on the gfx team really understands the ownership model around PGrallocBufferParent/PGrallocBufferChild. The question is how to define a clear ownership model so that we don't Send__delete__ on an already-deleted PGrallocBufferParent. So we've been shooting in the dark there. We'll keep shooting until it works ;-) alternatively if someone wants to educate us, that would be very welcome. CC'ing other people who've been looking into this kind of issues during the refactoring.
Good to know it's already in your sights. The video app is also crashing. The crash stack isn't as helpful though. See bug 864800.
It turns out that this also blocks me from further work on bug 864017, as it crashes before I get to reproduce that bug, so I guess I'll work on it now. Again I can't make strong promises as we've been banging our heads on this one before.
Snorp, can you help here?
Flags: needinfo?(snorp)
(In reply to Milan Sreckovic [:milan] from comment #8) > Snorp, can you help here? I can try, sure.
Flags: needinfo?(snorp)
Is the stack from bug 862324 of any help? STR from 1.0.1 "works for me now" bug 860079.
Maybe a regression? Not sure if it's related to bug 862230/bug 830008/bug 827833
Crash Signature: [@ mozalloc_abort(char const*) | NS_DebugBreak | mozilla::layers::PGrallocBufferParent::Write()] → [@ mozalloc_abort(char const*) | NS_DebugBreak | mozilla::layers::PGrallocBufferParent::Write()] [@ mozalloc_abort | NS_DebugBreak_P | mozilla::layers::PImageContainerChild::FatalError ]
We have some ideas about how to fix this. We're going to confirm that they are the correct approach now.
Bug 862324 is where the most activity on this issue is. It may very well be a dupe, but we're not making that call yet.
Good news: the patch in bug 862324 fixes this. Without the patch, I reproduce with exactly the same stack. With the patch, I don't reproduce any crash anymore when switching to the camcorder.
Depends on: 862324
Cool! I can re-verify once it lands.
It's landed on central now.
Works! I now see a crash when the recording finished. Progress!? I filed bug 866781
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 879681
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: