766867 - java.lang.NullPointerException: at org.mozilla.gecko.GeckoApp$23.run(GeckoApp.java)

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Scoobidiver (away)]

There's one crash in 16.0a1/20120620: bp-b95cce3b-8a1f-4a7c-830d-808f42120620.

java.lang.NullPointerException
	at org.mozilla.gecko.GeckoApp$23.run(GeckoApp.java:1348)
	at android.os.Handler.handleCallback(Handler.java:587)
	at android.os.Handler.dispatchMessage(Handler.java:92)
	at android.os.Looper.loop(Looper.java:132)
	at org.mozilla.gecko.GeckoBackgroundThread.run(GeckoBackgroundThread.java:31)

More reports at:
https://crash-stats.mozilla.com/report/list?signature=java.lang.NullPointerException%3A+at+org.mozilla.gecko.GeckoApp%2423.run%28GeckoApp.java%29

Comment 1

[Scoobidiver (away)]

There are currently 9 crashes. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=373e6f9264e6&tochange=c3190d715044

Comment 2

[Scoobidiver (away)]

The Aurora regression range is:
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=e5f9e8f2816f&tochange=d557426b0c8d
It's likely a regression from bug 765941.

Comment 3

[Scoobidiver (away)]

It's #6 top crasher in 15.a2 over the last 3 days.

Comment 4

[Brian Nicholson (:bnicholson)]

Attachment: Check if oldURL is null

tab.getURL() can return null; this NPE likely thrown when we call oldURL.equals().

Comment 5

[Matt Brubeck (:mbrubeck)]

Comment on attachment 636945 [details] [diff] [review]
Check if oldURL is null

Hmm... if getURL returns null both times, should we run the delayed stuff or not?  Are there steps to reproduce this?

r+ because this fixes the crash and returns us to the previous behavior, but I'm curious if there's something better we should do here.

Comment 6

[Brian Nicholson (:bnicholson)]

Attachment: Use null-safe string comparison for oldURL

(In reply to Matt Brubeck (:mbrubeck) from comment #5)
> Comment on attachment 636945 [details] [diff] [review]
> Check if oldURL is null
> 
> Hmm... if getURL returns null both times, should we run the delayed stuff or
> not?  Are there steps to reproduce this?
> 
> r+ because this fixes the crash and returns us to the previous behavior, but
> I'm curious if there's something better we should do here.

You're right - this wasn't the best approach. We shouldn't bail if oldURL is null since the new URL may be valid. In fact, even if the new URL is null, I assume it's still okay to take a screenshot, but I can't verify this. I've hit this NPE a few times today when I play around with the tabs tray (creating and removing tabs), but I don't have reliable STR.

Comment 7

[Brian Nicholson (:bnicholson)]

Bleh, sorry...got confused. We *don't* take the screenshot if they aren't equal. This patch makes it so that we *do* take the screenshot if it's null both times, which I hope is fine. I'll play around with the tabs tray to make sure I can't reproduce the crash again.

Comment 8

[Brian Nicholson (:bnicholson)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/2791940fb1ff

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/2791940fb1ff

Comment 10

[Scoobidiver (away)]

It's #3 top crasher in 15.0a2.

Comment 11

[Brian Nicholson (:bnicholson)]

Comment on attachment 636963 [details] [diff] [review]
Use null-safe string comparison for oldURL

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 765941
User impact if declined: potential crash on redirects
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): very low risk
String or UUID changes made by this patch: none

Comment 12

[Brian Nicholson (:bnicholson)]

http://hg.mozilla.org/releases/mozilla-aurora/rev/fc5fcbb7d152