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

Status: RESOLVED FIXED

Description

[Scoobidiver (away)]

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

Comment 1

[Scoobidiver (away)]

Currently hit by two users. A comment says: "occurred on PC single host test page with real streams".

Comment 2

[Jason Smith [:jsmith]]

(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?

Comment 3

[Jason Smith [:jsmith]]

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.

Comment 4

[Jason Smith [:jsmith]]

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).

Comment 5

[Jason Smith [:jsmith]]

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.

Comment 6

[Jason Smith [:jsmith]]

Not a blocker for pref on.

Comment 7

[bhavana bajaj [:bajaj]]

tracking because it is blocking [android-gum+].

Comment 8

[bhavana bajaj [:bajaj]]

Passing this to :gcp for help with investigation here (based on the outstanding needsinfo request), please reassign if needed

Comment 9

[Jason Smith [:jsmith]]

This definitely appears to be quite a prominent crash on FxAndroid right now in WebRTC land. Lots of new reports.

Comment 10

[Aaron Train [:aaronmt]]

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?

Comment 11

[Gian-Carlo Pascutto [:gcp]]

If the STR work (even if they need a few attempts), that should be good enough. I haven't tried yet.

Comment 12

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 13

[Gian-Carlo Pascutto [:gcp]]

Attachment: Patch 1. Avoid double-release of Camera object

Comment 14

[Gian-Carlo Pascutto [:gcp]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e8abfcbe1c32

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e8abfcbe1c32

Comment 16

[Jason Smith [:jsmith]]

We should verify this by checking in two weeks to see if there are still crashes present or not.

Comment 17

[Jason Smith [:jsmith]]

We should also consider uplifting this.

Comment 18

[Gian-Carlo Pascutto [:gcp]]

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

Comment 19

[Gian-Carlo Pascutto [:gcp]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/6f0387d46402

Comment 20

[Jason Smith [:jsmith]]

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.

Comment 21

[Jason Smith [:jsmith]]

Followup filed in bug 893239.