Look ma! I just triggered a segfault in nsTypeAheadFind.cpp

Ben Bucksch ben.bucksch at beonex.com
Tue Dec 27 23:10:29 UTC 2011


On 27.12.2011 23:37, Jonathan Protzenko wrote:
> *tl;dr:* by moving the location of the FindToolbar DOM node in 
> Thunderbird, I managed to make the entire program crash in 
> nsTypeAheadFind.cpp:990
>

For the lazy ones:
<http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/components/typeaheadfind/nsTypeAheadFind.cpp#990>
That means: for the typeahead, the nsPresShell is there, but its 
nsPresContext is null.

> I then change the findbar's browserid attribute to "multimessage", 
> summon the error console and run:
>
> top.opener.document.getElementById("FindToolbar").onFindCommand()
>
> As soon as I start typing something into the find bar, Thunderbird 
> segfaults brutally. I tried to read the code, and I think I should 
> call nsITypeAheadFind::SetDocShell somehow, but I can't seem to find 
> the nsITypeAheadFind instance associated to the <findbar>. Moreover, I 
> thought that changing the browserid attribute would do the trick since 
> it's what Thunderbird is doing already.
>
> Even *without* changing the browserid attribute, it still segfaults.
>
> I'm a little bit puzzled as to why changing the mere location of a DOM 
> node should make Thunderbird crash so badly.

I don't know the code at hand, but FWIW:

I think the crash is merely a symptom of what you described earlier. The 
point of crash suggests that, too. It's probably crashing because the 
findbar is there, but the content pane that it's supposed to search in 
is hidden, or something like that.

Of course, it's always possible that there's moronic code in findbar 
that does this.parentNode.firstChild.getAttribute() and similar 
nonsense, wouldn't be the first time I saw that in Mozilla code, but the 
existance of the browserid attribute suggests that this was written 
properly.

Tests:
1. Are you crashing, if you take an otherwise unmodified Thunderbird 
without Conversation extension and move the <findbar>, this being the 
only change? (If so, it could still be related to the <findbar> being 
there although its content pane is hidden.)
2. Are you also crashing, if you do *not* move the <findbar> and call 
onFindCommand() even though it's hidden?
Try to narrow down the problem with systematic tests like that.

Research:
In which conditions would there be a nsPresShell, but the nsPresContext 
of it would be null?

Ben



More information about the tb-planning mailing list