B2G crash in [@ mozalloc_abort | NS_DebugBreak_P | mozilla::layers::PImageContainerChild::FatalError]

VERIFIED FIXED in Firefox 21

Status

P2
critical
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: marcia, Assigned: tnikkel)

Tracking

(4 keywords)

unspecified
B2G C4 (2jan on)
ARM
Gonk (Firefox OS)
crash, reproducible, topcrash, unagi
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:tef+, blocking-basecamp:-, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18+ fixed, b2g18-v1.0.0 fixed)

Details

(Whiteboard: [b2g-crash][BTG-959][shadow:bjacob], crash signature)

Attachments

(1 attachment)

This bug was filed from the Socorro interface and is 
report bp-1c5af444-9f23-4674-b8ee-871f02130108 .
============================================================= 

Seen while running unagi, using:

Gecko: fcf2a2a59ec0
Gaia: fbe74c8441c3

STR:
1. Start the music app, and being playing an individual track.
2. Hit to the home button to switch to the camera app
3. Tap the camera button.
4. Crash - https://crash-stats.mozilla.com/report/index/1c5af444-9f23-4674-b8ee-871f02130108

I can reproduce this crash on my device. I am not tapping rapidly when this occurs, just going with the normal flow that a user might follow.

https://crash-stats.mozilla.com/report/index/8ec61719-8459-452b-accf-aec0d2130108 is my second crash.
mike, can you take a look?
Will try to grab a logcat in a moment.
sotaro, is this similar to the issue you're investigating?
mikeh, the crash thread's stack is almost same to Bug 826829.
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%20|%20NS_DebugBreak_P%20|%20mozilla::layers::PImageContainerChild::FatalError shows all the crashes in crash stats, so it looks as if a few other folks hit it besides me, using different build IDs.
(In reply to Sotaro Ikeda [:sotaro] from comment #4)
> mikeh, the crash thread's stack is almost same to Bug 826829.

this happens when parent side returns already deleted gralloc buffer to child side.
This looks a lot like bug 826829, except with a better stack.  Hopefully bug 824224 had a positive effect on that after all.

Updated

6 years ago
Depends on: 826829
Whiteboard: [b2g-crash]
Is it a dupe of bug 826829 ?
blocking-basecamp: ? → +
Priority: -- → P2
Target Milestone: --- → B2G C4 (2jan on)
Component: Gaia::Camera → General
QA Contact: jhammink
Jet, can we get somebody that does layout to take a look?
Assignee: nobody → bugs
(In reply to David Scravaglieri [:scravag] from comment #8)
> Is it a dupe of bug 826829 ?

tn will try to repro both and compare stacks.
Assignee: bugs → tnikkel
Tim, did you have a chance to set up the build?
(Assignee)

Comment 12

6 years ago
Got a build, learning to flash now.
I'm having trouble reproducing this. It happened once for me, but not when I had gdb attached unfortunately.

What happens instead is that the camera app never resumes preview mode when I switch back to it. I'm stuck with either an black screen, or the previous image, and the take picture/switch to video buttons are disabled.

I tried forcibly enabling the buttons by editing camera.js in gaia, and that instead leads to just the camera app crashing when I try take a photo.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 580.663]
android::IMemory::pointer (this=<value optimized out>) at frameworks/base/libs/binder/IMemory.cpp:149
149	    sp<IMemoryHeap> heap = getMemory(&offset);
(gdb) bt
#0  android::IMemory::pointer (this=<value optimized out>) at frameworks/base/libs/binder/IMemory.cpp:149
#1  0x407f93de in mozilla::GonkCameraHardware::DataCallback (aMsgType=<value optimized out>, aDataPtr=..., aMetadata=0x0, aUser=<value optimized out>)
    at /home/matt/b2g/gecko/dom/camera/GonkCameraHwMgr.cpp:94
#2  0x407f8ecc in android::CameraHardwareInterface::__data_cb (msg_type=256, data=<value optimized out>, index=<value optimized out>, metadata=0x0, user=0x43f332e0)
    at /home/matt/b2g/frameworks/base/services/camera/libcameraservice/CameraHardwareInterface.h:474
#3  0x423943b0 in android::QualcommCameraHardware::receiveRawPicture(int, msm_frame*, msm_frame*) () from /home/matt/b2g/out/target/product/otoro/system/lib/hw/camera.msm7627a.so
#4  0x423943b0 in android::QualcommCameraHardware::receiveRawPicture(int, msm_frame*, msm_frame*) () from /home/matt/b2g/out/target/product/otoro/system/lib/hw/camera.msm7627a.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) frame 1
#1  0x407f93de in mozilla::GonkCameraHardware::DataCallback (aMsgType=<value optimized out>, aDataPtr=..., aMetadata=0x0, aUser=<value optimized out>)
    at /home/matt/b2g/gecko/dom/camera/GonkCameraHwMgr.cpp:94
94	        ReceiveImage(camera, (uint8_t*)aDataPtr->pointer(), aDataPtr->size());
(gdb) p aDataPtr
$1 = (const android::sp<android::IMemory> &) @0x445bfc34: {m_ptr = 0x0}

Were the original STR done with the camera app already running and changing apps using a long press on the home key? Or just tap, and then run camera from the homescreen.

The former is what I'm doing, the latter has the same results if the camera app is already running, and works fine if it has to launch the camera app.
(In reply to Matt Woodrow (:mattwoodrow) from comment #13)
> I'm having trouble reproducing this. It happened once for me, but not when I
> had gdb attached unfortunately.
> 
> What happens instead is that the camera app never resumes preview mode when
> I switch back to it. I'm stuck with either an black screen, or the previous
> image, and the take picture/switch to video buttons are disabled.
> 

In Bug 826829, I also faced similar situations. In it's case, it was because of deadlock at GonkNativeWindow. attachment 699888 [details] [diff] [review] soloves the deadlock.
We'll definitely take a fix for these 3 related bugs so please don't stop working on them, but we won't hold the release for a camera app crasher that the user can easily work around.
blocking-basecamp: + → -
tracking-b2g18: --- → +

Updated

6 years ago
Crash Signature: [@ mozalloc_abort | NS_DebugBreak_P | mozilla::layers::PImageContainerChild::FatalError] → [@ mozalloc_abort | NS_DebugBreak_P | mozilla::layers::PImageContainerChild::FatalError] [@ mozalloc_abort(char const*) | NS_DebugBreak_P | mozilla::layers::PImageContainerChild::FatalError(char const*) const]
(In reply to Sotaro Ikeda [:sotaro] from comment #14)
> 
> In Bug 826829, I also faced similar situations. In it's case, it was because
> of deadlock at GonkNativeWindow. attachment 699888 [details] [diff] [review]
> soloves the deadlock.

The patches from bug 826829 don't fix my problem.

May be a similar problem though, how did you diagnose that issue? I'm not familiar with the camera code.
My way of diagnose is not smart...I manually added a lot of logoutputs to following files to trace enters and exit of the function.
- /gecko/dom/camera/GonkCameraControl.cpp
- /gecko/dom/camera/GonkNativeWindow.cpp
- /gecko/dom/camera/GonkNativeWindow.h
- /gecko/dom/camera/GonkCameraHwMgr.cpp
- gecko/gfx/layers/ipc/ImageBridgeChild.cpp
- gecko/gfx/layers/ipc/ImageBridgeParent.cpp
- gecko/gfx/layers/ipc/ImageContainerChild.cpp
- gecko/gfx/layers/ipc/ImageContainerParent.cpp
Created attachment 700821 [details]
ImageBridgeChild.cpp logout added manually

This file is a one of the files that I manually added logouts.
It's #2 top crasher in B2G 18.0.
Keywords: topcrash
(In reply to Scoobidiver from comment #19)
> It's #2 top crasher in B2G 18.0.

Probably worth noming if it's a topcrasher. Feel free to use tef? if you find a top crasher on b2g 18.
blocking-b2g: --- → tef?
Duplicate of this bug: 830008
blocking-b2g: tef? → tef+
Duplicate of this bug: 829960
Blocks: 808607
Whiteboard: [b2g-crash] → [b2g-crash][BTG-959]
Whiteboard: [b2g-crash][BTG-959] → [b2g-crash][BTG-959][shadow:bjacob]
I crashed on launching camera just now.
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/67503cae6a5a
Gaia   a03f7b532e9998e646d55f93a0fc03a04d7ca7d9
BuildID 20130115070201
Version 18.0

https://crash-stats.mozilla.com/report/index/58384b73-2281-45f4-840c-56f5d2130115
Patch are working their way through the system in bug 826829.
Patches are working their way through the system in bug 826829.
(Assignee)

Comment 26

6 years ago
I was able to reproduce this before bug 826829, but after applying the patches from bug 826829 I could no longer reproduce. So hopefully this is fixed.

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
status-b2g18: --- → fixed
status-firefox21: --- → fixed
Resolution: --- → FIXED
status-firefox19: --- → wontfix
status-firefox20: --- → wontfix
Duplicate of this bug: 832113
Landed on mozilla-b2g18/gaia master prior to the 1/25 branching to mozilla-b2g18_v1_0_0/v1.0.0, updating status-b2g-v1.0.0 to fixed.
status-b2g18-v1.0.0: --- → fixed

Comment 29

6 years ago
Verified this has been fixed on Unagi Build 20130219070200 Dec 5 Kernel
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.