crash in java.lang.NullPointerException: at org.webrtc.videoengine.VideoCaptureAndroid.onPreviewFrame(VideoCaptureAndroid.java)

RESOLVED FIXED in mozilla27

Status

()

--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jsmith, Assigned: jsmith)

Tracking

(Blocks: 1 bug, {crash})

24 Branch
mozilla27
All
Android
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [native-crash], crash signature)

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
This bug was filed from the Socorro interface and is 
report bp-9cc974fc-ab81-407d-a700-7ffec2130918.
=============================================================

java.lang.NullPointerException
	at org.webrtc.videoengine.VideoCaptureAndroid.onPreviewFrame(VideoCaptureAndroid.java:341)
	at android.hardware.Camera$EventHandler.handleMessage(Camera.java:791)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:137)
	at android.app.ActivityThread.main(ActivityThread.java:5303)
	at java.lang.reflect.Method.invokeNative(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:525)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:739)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:555)
	at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:112)
	at dalvik.system.NativeStart.main(Native Method)

https://crash-stats.mozilla.com/report/list?signature=java.lang.NullPointerException%3A+at+org.webrtc.videoengine.VideoCaptureAndroid.onPreviewFrame%28VideoCaptureAndroid.java%29&product=FennecAndroid&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2013-09-19+03%3A00%3A00&range_value=4
(Assignee)

Updated

5 years ago
Blocks: 750010
Version: 26 Branch → 24 Branch
(Assignee)

Updated

5 years ago
Whiteboard: [native-crash]

Comment 2

5 years ago
jason, want to patch it? :)
(Assignee)

Comment 3

5 years ago
Created attachment 811631 [details] [diff] [review]
Null check data to prevent NullPointerException v1
(Assignee)

Updated

5 years ago
Attachment #811631 - Flags: review?(gpascutto)
(Assignee)

Updated

5 years ago
Assignee: nobody → jsmith
Status: NEW → ASSIGNED
Comment on attachment 811631 [details] [diff] [review]
Null check data to prevent NullPointerException v1

Review of attachment 811631 [details] [diff] [review]:
-----------------------------------------------------------------

At first sight I was afraid this was plastering over another error in our WebRTC code and potentially making it harder to find, but this function is in fact only ever called from Android system code, so it's not our fault as far as I can tell.

We should probably look if this is specific to certain devices and/or file an upstream bug. Note that we have other code that's assuming data can't be null there:
http://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/device/CameraStreamImpl.cpp#l38

From a bit of Googling, this might be a bug in certain ROMs.
Attachment #811631 - Flags: review?(gpascutto) → review+
(Assignee)

Comment 5

5 years ago
(In reply to Gian-Carlo Pascutto (:gcp) from comment #4)
> Comment on attachment 811631 [details] [diff] [review]
> Null check data to prevent NullPointerException v1
> 
> Review of attachment 811631 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> At first sight I was afraid this was plastering over another error in our
> WebRTC code and potentially making it harder to find, but this function is
> in fact only ever called from Android system code, so it's not our fault as
> far as I can tell.
> 
> We should probably look if this is specific to certain devices and/or file
> an upstream bug. Note that we have other code that's assuming data can't be
> null there:
> http://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/device/
> CameraStreamImpl.cpp#l38
> 
> From a bit of Googling, this might be a bug in certain ROMs.

Crash stats over the past 28 days shows this only reproducing on a LG Optimus G twice. It probably is device-specific. We probably should file an upstream bug as well.

For those of us who don't know about the upstream process - What needs to be done here for this patch to get upstreamed (e.g. where would I file a bug)?
Keywords: checkin-needed
>It probably is device-specific. We probably should file an upstream bug as well.

Well, your analysis sortof reduces the urgency of doing so greatly, as this looks like a bug in a single device and maybe even a single non-standard ROM :)

>For those of us who don't know about the upstream process - What needs to be done here for this patch to get upstreamed (e.g. where would I file a bug)?

For Android bugs: http://code.google.com/p/android/issues/list  [New Issue] and pray (I've seldom or never seen a reaction)

For WebRTC.org upstream: First check if upstream has the same code, i.e. if the bug isn't in a modification on our side: 
https://code.google.com/p/webrtc/source/checkout

Then file here: http://code.google.com/p/webrtc/issues/list  Upstream is generally responsive and receptive to patches.
https://hg.mozilla.org/mozilla-central/rev/b5b45b437292
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
It looks like Bug 932112 accidentally backed this out.
Looks like just the dataLengthStr in the log message; the rest appears the same.

Updated

5 years ago
Blocks: 979024
You need to log in before you can comment on or make changes to this bug.