Closed Bug 1263808 Opened 8 years ago Closed 8 years ago

crash in java.lang.NullPointerException: Null native pointer at org.mozilla.gecko.gfx.NativePanZoomController.disposeNative(Native Method)

Categories

(Core Graveyard :: Widget: Android, defect)

All
Android
defect
Not set
critical

Tracking

(firefox47 disabled, firefox48 wontfix, firefox49 fixed, fennec48+, firefox50 fixed, firefox51 fixed)

RESOLVED FIXED
mozilla51
Tracking Status
firefox47 --- disabled
firefox48 --- wontfix
firefox49 --- fixed
fennec 48+ ---
firefox50 --- fixed
firefox51 --- fixed

People

(Reporter: jchen, Assigned: jchen)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(4 files)

This bug was filed from the Socorro interface and is 
report bp-ca2be46b-86cb-4b7b-a3f2-db50e2160408.
=============================================================

The first crashes are from the 4/07 Nightly, so I think it may be a regression from bug 1257959.
This seems to be in generated wrapper code? I'm having a hard time following this shutdown code, but it looks like the NPE is thrown from somewhere in [1]? That can't be right...

[1] http://mxr.mozilla.org/mozilla-central/source/widget/android/nsWindow.cpp?rev=cce22ba996a6#432
Yeah, the wrapper code threw the exception because the NPZC instance has already been "disposed" (or has not been initialized) when calling disposeNative. disposeNative is called by NativePanZoomController.destroy [1], which guards against being called twice. So I think NativePanZoomController.destroy is actually being called too early, before NPZC has initialized. That doesn't appear to be directly related to bug 1257959, but maybe it's a side-effect.

[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/gfx/NativePanZoomController.java?rev=21bf1af375c1#246
This is one of our top crashes on Nightly right now.
tracking-fennec: --- → ?
Assignee: nobody → rbarker
Comment on attachment 8743062 [details] [diff] [review]
0001-Bug-1263808-Prevent-NativePanZoomController.disposeNative-from-being-called-before-NPZCSupport-has-attached.-r-16041916-7083555.patch

I am unable to reproduce this. After discussion with :snorp, I believe this is what we agreed could possibly prevent the exception from being thrown at the possibility that NPZCSupport might leak.
Attachment #8743062 - Flags: review?(nchen)
[Tracking Requested - why for this release]: Should be fixed before APZ goes to release.
tracking-fennec: ? → 48+
Comment on attachment 8743062 [details] [diff] [review]
0001-Bug-1263808-Prevent-NativePanZoomController.disposeNative-from-being-called-before-NPZCSupport-has-attached.-r-16041916-7083555.patch

I have a suspicion that this is related to bug 1260451, which was fixed in the 4/16 nightly. We can revisit this if we get crash reports from after that nightly.
Attachment #8743062 - Flags: review?(nchen)
I don't see any of these past the 20160414030247 nightly, so I think we can close it and reopen it if comes back.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Version: unspecified → Trunk
This is looking pretty bad in 48: #10 topcrash with 2887 reports in the past week.
Flags: needinfo?(bugmail)
Switching needinfo to :rbarker as :kats is away this week
Flags: needinfo?(rbarker)
Flags: needinfo?(bugmail)
Jim, should we try landing this patch now or is there something else you would like to try first?
Flags: needinfo?(rbarker) → needinfo?(nchen)
This crash doesn't appear in the Beta top crashes, so maybe it's not as bad, but I guess we should fix it. I can work on it.
Assignee: rbarker → nchen
Status: RESOLVED → REOPENED
Flags: needinfo?(nchen)
Resolution: WORKSFORME → ---
Basically the same as the other patch except using mGeckoisReady in
GeckoLayerClient as the flag. Also guard against a case where
LayerView.onSizeChanged is called after LayerView destruction and results in a
NPE from mCompositor being null.
Attachment #8779754 - Flags: review?(rbarker)
Comment on attachment 8779754 [details] [diff] [review]
Guard against premature LayerView destruction (v1)

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

Of course I was in the process of trying to remove PanZoomTarget. But that may not possible anyway.
Attachment #8779754 - Flags: review?(rbarker) → review+
Pushed by nchen@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0ff858bf7e79
Guard against premature LayerView destruction; r=rbarker
Comment on attachment 8779754 [details] [diff] [review]
Guard against premature LayerView destruction (v1)

Approval Request Comment
[Feature/regressing bug #]: N/A
[User impact if declined]: Possible crash when using Fennec (one of current top crashes on release)
[Describe test coverage new/current, TreeHerder]: Locally
[Risks and why]: Small; only thing patch does is to avoid crash condition
[String/UUID change made/needed]: None
Attachment #8779754 - Flags: approval-mozilla-beta?
Attachment #8779754 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/0ff858bf7e79
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Hi Sylvestre, Kevin, I was reviewing this bug for uplift to Aurora and noticed that this seems to be a top crasher on Fennec48 (at spot #11). Is this something we would want to include in the 48.0.1 that is being planned? Just fyi it seems like a good ride-along.
Flags: needinfo?(sledru)
Flags: needinfo?(kbrosnan)
Comment on attachment 8779754 [details] [diff] [review]
Guard against premature LayerView destruction (v1)

Crash fix, let's validate on Aurora50 and Beta49 so we can consider taking this as a ride-along in 48.0.x.
Attachment #8779754 - Flags: approval-mozilla-beta?
Attachment #8779754 - Flags: approval-mozilla-beta+
Attachment #8779754 - Flags: approval-mozilla-aurora?
Attachment #8779754 - Flags: approval-mozilla-aurora+
I don't see any reports of this on 49 https://mozilla.github.io/bug-signatures-status/#/bug/1263808?_k=yipag2 though there are some crashes on 50 and 51. Odd.

Crash stats reports that this is 1% of total crashes so it is a significant win. While this is several changes they look to be checking for null values and making sure gecko is active.
Flags: needinfo?(kbrosnan)
This doesn't appear to apply cleanly to aurora.
Flags: needinfo?(nchen)
Flags: needinfo?(nchen)
Attachment #8781255 - Flags: review+
Flags: needinfo?(sledru)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: