Closed Bug 880437 Opened 9 years ago Closed 9 years ago
.lang .Null Pointer Exception: at org .webrtc .videoengine .Video Capture Android .Delete Video Capture Android(Video Capture Android .java)
There's one crash in 24.0a1/20130606: bp-084db911-edf6-4eaa-bb16-4ac722130606. java.lang.NullPointerException at org.webrtc.videoengine.VideoCaptureAndroid.DeleteVideoCaptureAndroid(VideoCaptureAndroid.java:77) at dalvik.system.NativeStart.run(Native Method) More reports at: https://crash-stats.mozilla.com/report/list?signature=java.lang.NullPointerException%3A+at+org.webrtc.videoengine.VideoCaptureAndroid.DeleteVideoCaptureAndroid%28VideoCaptureAndroid.java%29
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?
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 http://mozilla.github.io/webrtc-landing/pc_test.html 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.
Whiteboard: [native-crash][getUserMedia][android-gum-] → [native-crash][getUserMedia][android-gum+]
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.
Passing this to :gcp for help with investigation here (based on the outstanding needsinfo request), please reassign if needed
Assignee: nobody → 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) → review+
Status: NEW → RESOLVED
Closed: 9 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.
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: https://crash-stats.mozilla.com/report/index/4e3601ee-6d57-4a9a-9c1c-1cbf82130710 Shows evidence this is still reproducing on a 7/9/2013 build. I'll file a followup for tracking.
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.