Closed Bug 964861 Opened 6 years ago Closed 5 years ago

crash in java.lang.NullPointerException: at org.mozilla.gecko.toolbar.ToolbarDisplayLayout.updateFromTab(ToolbarDisplayLayout.java)

Categories

(Firefox for Android :: General, defect, critical)

29 Branch
All
Android
defect
Not set
critical

Tracking

()

VERIFIED FIXED
Firefox 33
Tracking Status
firefox28 --- unaffected
firefox29 --- wontfix
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- verified
firefox33 --- verified
fennec + ---

People

(Reporter: aaronmt, Assigned: lucasr)

References

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

This bug was filed from the Socorro interface and is 
report bp-c31482de-7959-44ec-a98b-a75b82140126.
=============================================================

java.lang.NullPointerException
	at org.mozilla.gecko.toolbar.ToolbarDisplayLayout.updateFromTab(ToolbarDisplayLayout.java:267)
	at org.mozilla.gecko.toolbar.BrowserToolbar.onTabChanged(BrowserToolbar.java:531)
	at org.mozilla.gecko.Tabs$5.run(Tabs.java:595)
i also had this crash 8 times contentiously.

ID  : e79a3858-5377-4f81-916b-45b072140131
Setps to Reproduce this Issue 

1. Launch Nightly.
2. Go To Menu > Settings
3. Tap on mozilla
4. Tap on About Nightly.

Actual Result  : 

Crashed !!!!!!!!!

Expected Result  :

About Nightly Page should open.


Version  : Nightly 29.0a1 (2014-01-30)

Observations  :

1 - crash - Restart Nightly after crash reporter -> About Nightly Open
2 - crash - Restart Nightly after crash reporter -> About Nightly Open
3 - closed - Nightly closed  - Crash Reporter Not launched.  
4 - crash - Restart Nightly after crash reporter -> About Nightly Open
5 - crash - Restart Nightly after crash reporter -> About Nightly Open
6 - crash - Restart Nightly after crash reporter -> About Nightly Open
7 - crash - Restart Nightly after crash reporter -> About Nightly Open.
8 - closed - Nightly closed  - Crash Reporter Not launched. 
9 - crash - Restart Nightly after crash reporter -> About Nightly Open.
Attached file Nightly-crash.log
Logs are attached for this crash .
Assignee: nobody → lucasr.at.mozilla
Hi 
what happened to this bug
it's still in New state ?
Hi Ashish,

This bug is assigned but it is not a critically high-volume crash signature, albeit it is still decently sized so it's not a super high priority at the moment.

As for this signature — in the past 28 days, I see 327 crashes across all channels.

https://crash-stats.mozilla.com/report/list?product=FennecAndroid&range_unit=days&range_value=28&signature=java.lang.NullPointerException%3A+at+org.mozilla.gecko.toolbar.ToolbarDisplayLayout.updateFromTab%28ToolbarDisplayLayout.java%29
Status: NEW → ASSIGNED
tracking-fennec: --- → ?
Triage team wonders if this is mentorable.
tracking-fennec: ? → +
Flags: needinfo?(lucasr.at.mozilla)
(In reply to Kevin Brosnan [:kbrosnan] from comment #6)
> Triage team wonders if this is mentorable.

Kinda. The stacktrace is a bit weird. Might hard to debug. I'll try to have a look at it next week.
Flags: needinfo?(lucasr.at.mozilla)
Duplicate of this bug: 1003229
See bug 1003229. What's special about visiting about:firefox that triggers this crash on some devices?
Attachment #8368453 - Attachment mime type: text/x-log → text/plain
Bug 1003229 makes me a little worried.
I can't reproduce this in Fx29. Any known reliable STR? That would help figuring out what's going on here.
Flags: needinfo?(aaron.train)
I have yet been able to reproduce this. Ashish, which device are you using and which Android version?
Flags: needinfo?(ashish28.sirt)
Hi Aaron

This seems not be reproducible in fx32 .

I am using samsung galaxy S2 device

Android 4.1.2
Flags: needinfo?(ashish28.sirt)
Flags: needinfo?(aaron.train)
100% reproducible using comment 2 with Don't Keep Activities enabled.
Comment on attachment 8439205 [details] [diff] [review]
Don't to update the toolbar state before it gets attachted (r=bnicholson)

"Don't keep activities" causes updates to ToolbarDisplayLayout before it gets attached to a window. But ToolbarDisplayLayout can't be updated before it gets attached. Let's simply bail if that happens.
Attachment #8439205 - Flags: review?(bnicholson)
Comment on attachment 8439205 [details] [diff] [review]
Don't to update the toolbar state before it gets attachted (r=bnicholson)

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

Commit message nits: s/Don't to update/Don't update/, s/attachted/attached/
Attachment #8439205 - Flags: review?(bnicholson) → review+
Backed out for:
https://tbpl.mozilla.org/php/getParsedLog.php?id=41666192&tree=Fx-Team
/builds/slave/fx-team-and-000000000000000000/build/mobile/android/base/toolbar/ToolbarDisplayLayout.java:265: cannot find symbol
symbol  : method isAttachedToWindow()
location: class org.mozilla.gecko.toolbar.ToolbarDisplayLayout
        if (!isAttachedToWindow()) {
             ^

remote:   https://hg.mozilla.org/integration/fx-team/rev/0cab2f679356
Replace isAttachedToWindow() with a local boolean member. Pushed: 
https://hg.mozilla.org/integration/fx-team/rev/595c7791bb16
(In reply to Lucas Rocha (:lucasr) from comment #20)
> Replace isAttachedToWindow() with a local boolean member. Pushed: 
> https://hg.mozilla.org/integration/fx-team/rev/595c7791bb16

Why not just use getWindowToken() != null?
https://hg.mozilla.org/mozilla-central/rev/595c7791bb16
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 33
(In reply to Brian Nicholson (:bnicholson) from comment #21)
> (In reply to Lucas Rocha (:lucasr) from comment #20)
> > Replace isAttachedToWindow() with a local boolean member. Pushed: 
> > https://hg.mozilla.org/integration/fx-team/rev/595c7791bb16
> 
> Why not just use getWindowToken() != null?

Good point, forgot about this one. Not a big deal though. Do you feel strongly enough about it to want me to file a follow-up?
Flags: needinfo?(bnicholson)
(In reply to Lucas Rocha (:lucasr) from comment #23)
> Good point, forgot about this one. Not a big deal though. Do you feel
> strongly enough about it to want me to file a follow-up?

Nope, not a big deal like you said. Just curious if there was a reason.
Flags: needinfo?(bnicholson)
Although this would make a pretty good contributor bug!
Comment on attachment 8439205 [details] [diff] [review]
Don't to update the toolbar state before it gets attachted (r=bnicholson)

Approval Request Comment
[Feature/regressing bug #]: bug 944533
[User impact if declined]: Top crasher in Fx31 (#19) and Fx32 (#18).
[Describe test coverage new/current, TBPL]: No new instances of this crasher bug after this patch landed in Nightly (Fx33).
[Risks and why]: Low, simply guard against invalid update calls.
[String/UUID change made/needed]: n/a
Attachment #8439205 - Flags: approval-mozilla-aurora?
Attachment #8439205 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Tested with:
Device: Samsung Galaxy Nexus
OS: Android 4.2.1

After performing the steps from comment 2 and comment 14, about firefox beta is opened, so verified fixed on:
Build: Firefox for Android 32 Beta 1
Tested with:
Device: Samsung Galaxy Nexus
OS: Android 4.2.1

After performing the steps from comment 2 and comment 14, about firefox aurora is opened, so verified fixed on:
Build: Firefox for Android 33.0a2 Aurora (2014-07-24)
Status: RESOLVED → VERIFIED
Hi Margaret, Kevin: This bug is resolved & verified but the crash signature associated with it shows as top 3rd spot on Fennec Aurora 47. From the reports, I see the crash happening on 47.0a1 build 03-20. Should I re-open this or create a copy of this bug? Please let me know.
Flags: needinfo?(margaret.leibovic)
Flags: needinfo?(kbrosnan)
We should file a new bug.
Flags: needinfo?(kbrosnan)
Blocks: 1258523
Flags: needinfo?(margaret.leibovic)
You need to log in before you can comment on or make changes to this bug.