850845 - Camera - crash when trying to open a second camera instance

Status: VERIFIED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Mike Habicher [:mikeh] (high bugzilla latency)]

Following the STR in bug 846262 comment 5 causes the b2g parent process to crash when tapping the camera icon on the lockscreen.

logcat:
E(  118:0x265) Qint android::get_camera_info(int, camera_info*): E
I(  118:0x265) Found a matching camera info for ID 0
I(  118:0x265) HAL_getCameraInfo: orientation = 90
I(  118:0x265) HAL_getCameraInfo: modes supported = 5
W(  118:0x264) CameraService::connect X (pid 107) rejected (existing client).
F(  107:0x28a) Fatal signal 11 (SIGSEGV) at 0x00000024 (code=1)
I(  110:0x6e) debuggerd committing suicide to free the zombie!
I(  651:0x28b) debuggerd: Feb 28 2013 10:55:01

Observed on unagi with:
- gecko: inbound-src:80d1a17de628
- gaia: de3e5b9205e6cb1a6bd0858a98d159272ad96d11

Comment 1

[Mike Habicher [:mikeh] (high bugzilla latency)]

And the gdb backtrace:

[New Thread 997.1167]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 997.1167]
0x4145a1c4 in android::GonkCameraHardware::PullParameters (this=0x0, aParams=...) at /home/mikeh/dev/mozilla/m-c/inbound-src/dom/camera/GonkCameraHwMgr.cpp:281
281	  const String8 s = mCamera->getParameters();
(gdb) bt
#0  0x4145a1c4 in android::GonkCameraHardware::PullParameters (this=0x0, aParams=...) at /home/mikeh/dev/mozilla/m-c/inbound-src/dom/camera/GonkCameraHwMgr.cpp:281
#1  0x414579de in mozilla::nsGonkCameraControl::PullParametersImpl (this=0x4879f110) at /home/mikeh/dev/mozilla/m-c/inbound-src/dom/camera/GonkCameraControl.cpp:860
#2  0x41458004 in mozilla::nsGonkCameraControl::Init (this=0x4879f110) at /home/mikeh/dev/mozilla/m-c/inbound-src/dom/camera/GonkCameraControl.cpp:235
#3  0x41458150 in InitGonkCameraControl::Run (this=0x491d31c0) at /home/mikeh/dev/mozilla/m-c/inbound-src/dom/camera/GonkCameraControl.cpp:181
#4  0x41bce83a in nsThread::ProcessNextEvent (this=0x49472940, mayWait=<value optimized out>, result=0x4b8ffe87) at /home/mikeh/dev/mozilla/m-c/inbound-src/xpcom/threads/nsThread.cpp:627
#5  0x41b95c5c in NS_ProcessNextEvent_P (thread=0x0, mayWait=true) at /home/mikeh/dev/mozilla/btg019/objdir-gecko-inbound-debug/xpcom/build/nsThreadUtils.cpp:238
#6  0x41bcee8e in nsThread::ThreadFunc (arg=<value optimized out>) at /home/mikeh/dev/mozilla/m-c/inbound-src/xpcom/threads/nsThread.cpp:265
#7  0x4038e83c in _pt_root (arg=<value optimized out>) at /home/mikeh/dev/mozilla/m-c/inbound-src/nsprpub/pr/src/pthreads/ptthread.c:191
#8  0x400e4e18 in __thread_entry (func=0x4038e7a9 <_pt_root>, arg=0x493ac600, tls=<value optimized out>) at bionic/libc/bionic/pthread.c:217
#9  0x400e496c in pthread_create (thread_out=<value optimized out>, attr=0xbe9be5bc, start_routine=0x4038e7a9 <_pt_root>, arg=0x493ac600) at bionic/libc/bionic/pthread.c:357
#10 0x00000000 in ?? ()

this=0x0 in frame 0: looks like mCameraHw is null in

  mCameraHw->PullParameters(mParams);

It looks like nsGonkCameraControl::Init() doesn't handle failure of GonkCameraHardware::Connect() gracefully.  Easy enough to fix.

Comment 2

[Mike Habicher [:mikeh] (high bugzilla latency)]

Attachment: make sure we don't dereference a null mCameraHw pointer

Comment 3

[Michael Vines [:m1] [:evilmachines]]

(crash=tef+ assuming this even is an issue on v1.0.1 as the bug report is on inbound...)

Comment 4

[Scoobidiver (away)]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #3)
> assuming this even is an issue on v1.0.1
It is. See bp-b26a4ff6-fb22-4f45-bd5c-face12130313.

Comment 5

[Sotaro Ikeda [:sotaro]]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #3)
> (crash=tef+ assuming this even is an issue on v1.0.1 as the bug report is on
> inbound...)

The issues do not happen on v1.0.1. By Bug 803471, how to handle camera hw is changed. The change is applied from v1.1(leo).

Comment 6

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #5)
> (In reply to Michael Vines [:m1] [:evilmachines] from comment #3)
> > (crash=tef+ assuming this even is an issue on v1.0.1 as the bug report is on
> > inbound...)
> 
> The issues do not happen on v1.0.1. By Bug 803471, how to handle camera hw
> is changed. The change is applied from v1.1(leo).

on v1.01, the check is done within GonkCameraHardware. From v1.1, the check needs to be done in nsGonkCameraControl.

Comment 7

[Sotaro Ikeda [:sotaro]]

Comment on attachment 724638 [details] [diff] [review]
make sure we don't dereference a null mCameraHw pointer

Looks good to me and confirmed on unagi.

Comment 8

[Mike Habicher [:mikeh] (high bugzilla latency)]

try-server push: https://tbpl.mozilla.org/?tree=Try&rev=eaf039e732ae

Comment 9

[Mike Habicher [:mikeh] (high bugzilla latency)]

OPEN TREE \o/
https://hg.mozilla.org/integration/mozilla-inbound/rev/6d3f1e3ccf5c

Comment 10

[Mike Habicher [:mikeh] (high bugzilla latency)]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/568375a08f11

Comment 11

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/6d3f1e3ccf5c

Comment 12

[Daniel Coloma:dcoloma]

It is an issue for v1.0.1? If so, we need to set up flag status-b2g18-v1.0.1 accordingly.

Comment 13

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

https://crash-stats.mozilla.com/report/list?product=B2G&query_search=signature&query_type=exact&query=android%3A%3AGonkCameraHardware%3A%3APullParameters&reason_type=contains&date=03%2F19%2F2013%2001%3A45%3A20&range_value=1&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=android%3A%3AGonkCameraHardware%3A%3APullParameters

It happens more times on the 2013031411 build.  I think the 3/14 build was a bad build though.  I do recall getting a crash on the v1 train on this build.

I have not seen any further crashes of this since the patch on the 15th.  I do not recall seeing this crash on v1.0.1

Comment 14

[:CSchmoeckel]

Issue is fixed on latest build. No need for a MozTrap Test Case on this issue. 
"in-moztrap-"

Comment 15

[mdaniloff]

Changed to Verified-Fixed as per comment #14

Comment 16

[Mike Habicher [:mikeh] (high bugzilla latency)]

Follow-up to comment 12: v1.0.1 is not affected by this issue.