1055456 - Crash in [@ nsTypeAheadFind::GetSearchContainers]

Status: VERIFIED FIXED

(Toolkit :: Find Toolbar, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

https://crash-stats.mozilla.com/report/index/335cd18c-3f3f-40ee-9f70-c99232140819

(This is a blocker for me to use e10s builds. They crash all the time.
"Search for text when I start typing" enabled)

Comment 1

[Liz Henry (:lizzard) (relman/hg->git project)]

This is the #4 topcrasher for Firefox 34.0a1 for the last 7 days with 182/11183 crashes. It happens on Mac, Windows, and Linux.  The crash signature first appeared 2012-04-08 but the recent crashes only started up again with the 2014081703 build. 

Comments from other crash reports: 

"This crash seems to happen on about:newtab when I press a key with the focus on the page. It doesn't happen in about:blank, and doesn't seem to depend on whether about:newtab is in Blank or Classic mode. "

"I tried to search in my downloads - I pressed Ctrl+F on 'all downloads' tab and started to type '.24'. on first char window became blank and then Firefox died. RIP. "

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

I explicitly filed this for e10s, since that is where this is happening for me.

Comment 3

[cmtalbert]

(In reply to Olli Pettay [:smaug] from comment #2)
> I explicitly filed this for e10s, since that is where this is happening for
> me.

I hit it on a non-E10S nightly and it's nearly the same stack: https://crash-stats.mozilla.com/report/index/3d49e6ad-749f-40b1-8b02-edccd2140826

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Ah, most probably a regression from bug 263049

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Nothing guarantees a binding has anonymous content.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Attachment: null check

As far as I see, this is a null+offset crash.
So better to null check the return value of GetAnonymousContent().
And there is no need to null check 'child' since do_QueryInterface is null safe.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8479935 [details] [diff] [review]
null check

Wait, this isn't enough. There would be just more null pointer crashes.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8479935 [details] [diff] [review]
null check

No, this should be fine.
searchRootNode points to non-null rootNode, if we don't have anonContent.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 8479935 [details] [diff] [review]
null check

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

Sorry, I should have caught this in my original review.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

m-i is closed :(
I don't expect a null check needing a tryserver run.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/47f8093426c4

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/47f8093426c4

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

This crash signature stopped showing up so I'm marking it verified based on crash-stats.