Look ma! I just triggered a segfault in nsTypeAheadFind.cpp
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
For the lazy ones:
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:
> 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
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.
In which conditions would there be a nsPresShell, but the nsPresContext
of it would be null?
More information about the tb-planning