Closed Bug 880437 Opened 11 years ago Closed 11 years ago

java.lang.NullPointerException: at org.webrtc.videoengine.VideoCaptureAndroid.DeleteVideoCaptureAndroid(


(Firefox for Android Graveyard :: General, defect)

Not set


(firefox24+ fixed, firefox25 fixed, fennec+)

Firefox 25
Tracking Status
firefox24 + fixed
firefox25 --- fixed
fennec + ---


(Reporter: scoobidiver, Assigned: gcp)



(Keywords: crash, reproducible, Whiteboard: [native-crash][getUserMedia][android-gum+])

Crash Data


(1 file)

There's one crash in 24.0a1/20130606: bp-084db911-edf6-4eaa-bb16-4ac722130606.

	at org.webrtc.videoengine.VideoCaptureAndroid.DeleteVideoCaptureAndroid(
	at Method)

More reports at:
Whiteboard: [native-crash] → [native-crash][getUserMedia][android-gum-]
Currently hit by two users. A comment says: "occurred on PC single host test page with real streams".
(In reply to Scoobidiver from comment #1)
> Currently hit by two users. A comment says: "occurred on PC single host test
> page with real streams".

Ah, that was me. I was able to reproduce this twice using a combination of the gum test page and pc test page. I had to hammer requesting and releasing camera a bunch of times.

gcp - any ideas why this is happening?
Flags: needinfo?(gpascutto)
Here's STR that seems to reproduce the crash for me on a Galaxy Nexus running Android 4.2:

1. Start Nightly from a cold start (not running in the background)
2. Go to
3. Deselect the fake video option
4. Select start
5. Accept permissions for the back camera on both prompts
6. Wait until the connection is established (4 videos should be playing)
7. Try to reload the page

Result - Nightly will crash.
Keywords: reproducible
Whiteboard: [native-crash][getUserMedia][android-gum-] → [native-crash][getUserMedia][android-gum+]
tracking-fennec: --- → ?
My guess is this is a camera shutdown crash happening when we're releasing the camera in non-traditional means (e.g. closing a tab running the camera, reloading content running the camera).
One last note - comment 3's STR isn't going to 100% always reproduce the crash, but I have noticed it seems to reproduce the crash often enough if you keep trying that STR a few times.
Not a blocker for pref on.
tracking because it is blocking [android-gum+].
Passing this to :gcp for help with investigation here (based on the outstanding needsinfo request), please reassign if needed
Assignee: nobody → gpascutto
tracking-fennec: ? → +
Flags: needinfo?(gpascutto)
This definitely appears to be quite a prominent crash on FxAndroid right now in WebRTC land. Lots of new reports.
Struggling to reproduce on my HTC One (4.1) and Galaxy S4 (4.2.2) on Nightly 06/26 using the STR in comment #3. Is the current stack frame adequate for narrowing down the issue here?
If the STR work (even if they need a few attempts), that should be good enough. I haven't tried yet.
I can't reproduce this at all, but I see at least one callpath that could cause this crash: if you manage to get WebRTC to shut down after the application will be put into the background. The camera will be detached (and nulled) but DeleteVideoCaptureAndroid will try to release it again.

I'd still love better STR to be more sure of the cause, but I will patch the above case.
Attachment #770855 - Flags: review?(blassey.bugs)
Attachment #770855 - Flags: review?(blassey.bugs) → review+
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 25
We should verify this by checking in two weeks to see if there are still crashes present or not.
Keywords: verifyme
We should also consider uplifting this.
Whiteboard: [native-crash][getUserMedia][android-gum+] → [native-crash][getUserMedia][android-gum+][webrtc-uplift]
Comment on attachment 770855 [details] [diff] [review]
Patch 1. Avoid double-release of Camera object

The patch is simple and "obviously-correct" enough that we can put it on Aurora before verifying it fixes (all) the crashes.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Android WebRTC
User impact if declined: Potential crash in particular circumstances
Testing completed (on m-c, etc.): Landed on m-c few days ago
Risk to taking this patch (and alternatives if risky): Trivial patch to fix a double-free.
String or IDL/UUID changes made by this patch: NA
Attachment #770855 - Flags: approval-mozilla-aurora?
Attachment #770855 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Looks like the patch here didn't fix the bug:

Shows evidence this is still reproducing on a 7/9/2013 build.

I'll file a followup for tracking.
Keywords: verifyme
Followup filed in bug 893239.
Whiteboard: [native-crash][getUserMedia][android-gum+][webrtc-uplift] → [native-crash][getUserMedia][android-gum+]
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.