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)
Tracking
(firefox47 disabled, firefox48 wontfix, firefox49 fixed, fennec48+, firefox50 fixed, firefox51 fixed)
RESOLVED
FIXED
mozilla51
People
(Reporter: jchen, Assigned: jchen)
References
Details
(Keywords: crash, regression)
Crash Data
Attachments
(4 files)
5.88 KB,
patch
|
Details | Diff | Splinter Review | |
5.14 KB,
patch
|
rbarker
:
review+
ritu
:
approval-mozilla-aurora+
ritu
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
4.57 KB,
patch
|
jchen
:
review+
|
Details | Diff | Splinter Review |
4.52 KB,
patch
|
jchen
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•8 years ago
|
||
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
Assignee | ||
Comment 2•8 years ago
|
||
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
Updated•8 years ago
|
Blocks: fennec-aboard-apz
Comment 3•8 years ago
|
||
This is one of our top crashes on Nightly right now.
tracking-fennec: --- → ?
Updated•8 years ago
|
Assignee: nobody → rbarker
Comment 4•8 years ago
|
||
Comment 5•8 years ago
|
||
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)
Comment 6•8 years ago
|
||
[Tracking Requested - why for this release]: Should be fixed before APZ goes to release.
tracking-fennec: ? → 48+
status-firefox47:
--- → disabled
status-firefox48:
--- → affected
tracking-firefox48:
--- → ?
Assignee | ||
Comment 7•8 years ago
|
||
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)
Comment 8•8 years ago
|
||
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
Updated•8 years ago
|
status-firefox48:
affected → ---
tracking-firefox48:
? → ---
Updated•8 years ago
|
Version: unspecified → Trunk
This is looking pretty bad in 48: #10 topcrash with 2887 reports in the past week.
Flags: needinfo?(bugmail)
Comment 10•8 years ago
|
||
Switching needinfo to :rbarker as :kats is away this week
Flags: needinfo?(rbarker)
Updated•8 years ago
|
Flags: needinfo?(bugmail)
Comment 11•8 years ago
|
||
Jim, should we try landing this patch now or is there something else you would like to try first?
Flags: needinfo?(rbarker) → needinfo?(nchen)
Assignee | ||
Comment 12•8 years ago
|
||
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 → ---
Assignee | ||
Comment 13•8 years ago
|
||
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 14•8 years ago
|
||
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+
Comment 15•8 years ago
|
||
Pushed by nchen@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/0ff858bf7e79 Guard against premature LayerView destruction; r=rbarker
Assignee | ||
Comment 16•8 years ago
|
||
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?
Comment 17•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0ff858bf7e79
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
status-firefox51:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
status-firefox49:
--- → affected
status-firefox50:
--- → affected
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.
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+
Comment 20•8 years ago
|
||
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)
Assignee | ||
Comment 22•8 years ago
|
||
Attachment #8781254 -
Flags: review+
Assignee | ||
Comment 23•8 years ago
|
||
Flags: needinfo?(nchen)
Attachment #8781255 -
Flags: review+
Comment 24•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/e1604afddd41
Updated•8 years ago
|
Flags: needinfo?(sledru)
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•