Crash in java.lang.NullPointerException: Attempt to invoke virtual method ''boolean org.mozilla.gecko.Tab.isPrivate()'' on a null object reference at org.mozilla.gecko.BrowserApp.maybeSwitchToTab(BrowserApp.java)

RESOLVED FIXED in Firefox 58

Status

()

defect
--
critical
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Usul, Assigned: JanH)

Tracking

({crash})

unspecified
Firefox 59
All
Android
Points:
---

Firefox Tracking Flags

(firefox57 wontfix, firefox58 fixed, firefox59 fixed)

Details

(crash signature)

Attachments

(1 attachment)

This bug was filed from the Socorro interface and is
report bp-b6b9a209-3b6b-4314-8d6c-332e50171221.
=============================================================

Top 10 frames of crashing thread:

0 libxul.so GeckoAppShellSupport::ReportJavaCrash widget/android/nsAppShell.cpp:276
1 libxul.so mozilla::jni::NativeStub<mozilla::java::GeckoAppShell::ReportJavaCrash_t, GeckoAppShellSupport, mozilla::jni::Args<const mozilla::jni::Ref<mozilla::jni::TypedObject<_jthrowable*>, _jthrowable*>&, const mozilla::jni::StringParam&> >::Wrap<&GeckoAppShellSupport::ReportJavaCrash> widget/android/jni/Natives.h:778
2 base.odex base.odex@0x2186b 
3 dalvik-LinearAlloc (deleted) dalvik-LinearAlloc @0x48aa 
4 dalvik-main space (region space) (deleted) dalvik-main space @0xb9dce 
5 dalvik-main space (region space) (deleted) dalvik-main space @0xc3fffe 
6 dalvik-main space (region space) (deleted) dalvik-main space @0xc4001e 
7 libart.so libart.so@0x401775 
8 dalvik-main space (region space) (deleted) dalvik-main space @0xbd593e 
9 dalvik-main space (region space) (deleted) dalvik-main space @0xbe6b76 

=============================================================

java.lang.NullPointerException: Attempt to invoke virtual method 'boolean org.mozilla.gecko.Tab.isPrivate()' on a null object reference
	at org.mozilla.gecko.BrowserApp.maybeSwitchToTab(BrowserApp.java:2449)
	at org.mozilla.gecko.BrowserApp.onUrlOpenWithReferrer(BrowserApp.java:4243)
	at org.mozilla.gecko.BrowserApp.onUrlOpen(BrowserApp.java:4221)
	at org.mozilla.gecko.home.BrowserSearch$1.onItemClick(BrowserSearch.java:351)
	at org.mozilla.gecko.home.HomeListView$1.onItemClick(HomeListView.java:122)
	at android.widget.AdapterView.performItemClick(AdapterView.java:318)
	at android.widget.AbsListView.performItemClick(AbsListView.java:1158)
	at android.widget.AbsListView$PerformClick.run(AbsListView.java:3127)
	at android.widget.AbsListView$3.run(AbsListView.java:4042)
	at android.os.Handler.handleCallback(Handler.java:790)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:164)
	at android.app.ActivityThread.main(ActivityThread.java:6494)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
Assignee: nobody → jh+bugzilla
Hardware: Unspecified → All
This does seem a bit mysterious, as normally a tab should be selected as part of GeckoApp startup when either the last session is parsed for restoring (on the Java side!) or else the startup tab is opened. But evidently something still can go wrong.

There are e.g. other crash reports with short uptimes and a stack indicating that some Top Sites item was being clicked.
See Also: → 1426864
Comment on attachment 8938654 [details]
Bug 1426613 - Determine private mode via browser toolbar.

https://reviewboard.mozilla.org/r/209266/#review215094
Attachment #8938654 - Flags: review?(cnevinchen) → review+
(In reply to Jan Henning [:JanH] from comment #1)
> This does seem a bit mysterious, as normally a tab should be selected as
> part of GeckoApp startup when either the last session is parsed for
> restoring (on the Java side!) or else the startup tab is opened. But
> evidently something still can go wrong.
> 
> There are e.g. other crash reports with short uptimes and a stack indicating
> that some Top Sites item was being clicked.

While I still haven't managed to reproduce this in practice, one possible theory would involve the tab queue when not restoring any tabs from a previous session and then going via https://dxr.mozilla.org/mozilla-central/rev/e6f4a2d1df9a4a50b1b659f87dca99d88a5ef63a/mobile/android/base/java/org/mozilla/gecko/GeckoApp.java#1447.

If I'm reading our code right, in that case we first open the tab queue tabs indirectly by messaging Gecko and then wait for Gecko to have loaded and opened all those tabs before running the processActionViewIntent runnable. In that case we indeed wouldn't have any Java tabs open until Gecko is up and running, so if my theory is correct and startup takes somewhat longer (slow phone/we need to extract a fresh copy of libxul.so first/???) this could leave enough time for the user to click somewhere that triggers this crash.
Pushed by mozilla@buttercookie.de:
https://hg.mozilla.org/integration/autoland/rev/90f70240f409
Determine private mode via browser toolbar. r=nechen
https://hg.mozilla.org/mozilla-central/rev/90f70240f409
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 59
STR:
1. Set Firefox to not restore tabs automatically.
2. Enable Tab Queue.
3. Set Firefox as an Assist App for easier testing, as that'll open a new tab showing our home panels right after starting (Android Settings -> Apps -> settings icon -> Default apps -> Assist & voice input -> Assist app).
4. Kill Firefox.
5. Queue some tabs.
6. From Android's app settings for Firefox, clear the cache.
7. Long press the home button to launch Firefox via the assist app feature.
8. While Firefox is still busy extracting libxul.so (and the tabs counter is showing "0") select an entry (Top Site/history/bookmark/...) from the home panels or type something to search your history/bookmarks and then select a result.

Result: If you've completed step 8 before Gecko has loaded, Firefox will crash.
Depends on: 1352133
No longer depends on: 1352133
See Also: → 1352133
Comment on attachment 8938654 [details]
Bug 1426613 - Determine private mode via browser toolbar.

Approval Request Comment
[Feature/Bug causing the regression]: Awesomescreen
[User impact if declined]: Firefox could crash if the user interacts with the Awesomescreen before Firefox has opened any tabs.
[Is this code covered by automated tests?]: No.
[Has the fix been verified in Nightly?]: Tested locally.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: Bug 1426864 and bug 1352133 are very similar crashes that might also happen along the same code path, i.e. if only one bug is fixed you might still crash because of one of the other bugs.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: Instead of looking at the currently selected tab (which might not exist yet early during startup) we look at the browser toolbar (which is guaranteed to exist if the awesomescreen UI has loaded) to determine whether we're in private browsing or not.
[String changes made/needed]: none
Attachment #8938654 - Flags: approval-mozilla-beta?
Comment on attachment 8938654 [details]
Bug 1426613 - Determine private mode via browser toolbar.

Fix a crash related to Awesomescreen. Beta58+.
Attachment #8938654 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.