274625 - Random crashes when using fayt/find FF10 FFTrunk [@ nsTypeAheadFind::Find]

Status: RESOLVED FIXED

(Toolkit :: Find Toolbar, defect)

Description

[Markus Långström]

For a couple of days trunk builds have been crashing frequently while using FAYT
or Find. In most cases both FAYT and classic Find stop working right before the
segfault. Fresh profile didn't help.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041214
Firefox/1.0+

Talkback: TB2545754E, TB2545647W

Comment 1

[Bill Mason]

*** Bug 274627 has been marked as a duplicate of this bug. ***

Comment 2

[timeless]

Incident ID: 2545754 
Stack Signature nsTypeAheadFind::Find af3c084a 
Product ID FirefoxTrunk 
Build ID 2004121406 
Trigger Time 2004-12-14 11:44:03.0 
Platform Win32 
Operating System Windows NT 5.1 build 2600 
Module firefox.exe + (003d7b73) 
URL visited  
User Comments Random crashes when using FAYT. 
Since Last Crash 344 sec 
Total Uptime 675 sec 
Trigger Reason Access violation 
Source File, Line No. 
c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/toolkit/components/typeahe
adfind/src/nsTypeAheadFind.cpp, line 805 
Stack Trace  

nsTypeAheadFind::Find  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/toolkit/components/typeah
eadfind/src/nsTypeAheadFind.cpp, line 805]
XPTC_InvokeByIndex  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src
/md/win32/xptcinvoke.cpp, line 102]
XPCWrappedNative::CallMethod  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcw
rappednative.cpp, line 2034]
XPC_WN_CallMethod  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcw
rappednativejsops.cpp, line 1287]
js_Invoke  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 
1286]
js_Interpret  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 
3619]
js_Invoke  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 
1306]
nsXPCWrappedJSClass::CallMethod  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcw
rappedjsclass.cpp, line 1339]
nsXPCWrappedJS::CallMethod  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcw
rappedjs.cpp, line 450]
SharedStub  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src
/md/win32/xptcstubs.cpp, line 147]
nsEventListenerManager::HandleEventSubType  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/content/events/src/nsEven
tListenerManager.cpp, line 1519]
nsEventListenerManager::HandleEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/content/events/src/nsEven
tListenerManager.cpp, line 1596]
nsXULElement::HandleDOMEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/content/xul/content/src/n
sXULElement.cpp, line 2820]
nsXULElement::HandleDOMEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/content/xul/content/src/n
sXULElement.cpp, line 2839]
nsXULElement::HandleDOMEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/content/xul/content/src/n
sXULElement.cpp, line 2839]
nsXULElement::HandleDOMEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/content/xul/content/src/n
sXULElement.cpp, line 2839]
nsXULElement::HandleDOMEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/content/xul/content/src/n
sXULElement.cpp, line 2839]
nsXULElement::HandleChromeEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/content/xul/content/src/n
sXULElement.cpp, line 3948]
nsGlobalWindow::HandleDOMEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWind
ow.cpp, line 929]
nsDocument::HandleDOMEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocume
nt.cpp, line 3834]
nsGenericElement::HandleDOMEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/content/base/src/nsGeneri
cElement.cpp, line 2037]
PresShell::HandleEventInternal  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.c
pp, line 5917]
PresShell::HandleEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.c
pp, line 5772]
nsViewManager::HandleEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cp
p, line 2354]
nsViewManager::DispatchEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cp
p, line 2127]
HandleEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp, 
line 174]
nsWindow::DispatchEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWind
ow.cpp, line 1102]
nsWindow::DispatchKeyEvent  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWind
ow.cpp, line 3037]
nsWindow::OnChar  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWind
ow.cpp, line 3243]
nsWindow::ProcessMessage  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWind
ow.cpp, line 3927]
nsWindow::WindowProc  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWind
ow.cpp, line 1383]
USER32.dll + 0x8709 (0x77d38709)
USER32.dll + 0x87eb (0x77d387eb)
USER32.dll + 0x89a5 (0x77d389a5)
USER32.dll + 0x89e8 (0x77d389e8)
nsAppShell::Run  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsAppS
hell.cpp, line 159]
nsAppStartup::Run  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/toolkit/components/startu
p/src/nsAppStartup.cpp, line 156]
main  
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/browser/app/nsBrowserApp.
cpp, line 60]
kernel32.dll + 0x16d4f (0x7c816d4f)

Comment 3

[timeless]

*** Bug 274754 has been marked as a duplicate of this bug. ***

Comment 4

[sairuh (rarely reading bugmail)]

I've been encountering this off and on while using recent trunk builds --usually
in a situation similar to what's described in bug 274557 comment 3 and bug
274557 comment 4.

http://talkback-reports.mozilla.org/talkback/quicksearch.jsp?search=2&type=iid&id=2780704

http://talkback-reports.mozilla.org/talkback/quicksearch.jsp?search=2&type=iid&id=2772828

Comment 5

[sairuh (rarely reading bugmail)]

jay, have you been seeing (more) crash reports of this kind recently?

Comment 6

[Aaron Leventhal]

I'm too busy working on other accessibility issues to deal with find as you type
anymore. Sorry, we need a new module owner for it. I suppose Blake owns it now. 

Comment 7

[Jay Patel [:jay]]

Here is the Talkback query for all current crashes for nsTypeAheadFind::Find:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsTypeAheadFind%3A%3AFind&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

Adding topcrash keyword to get his on the radar since Sarah has been able to
reproduce this.  I have not been able to reproduce this with recent builds, but
there are enough crashes in current Talkback data to have someone take a look.

Anyone want to take a poke at this one?

Comment 8

[timeless]

for the record, this is a bug in the firefox fastfind code. it is not a bug in
the fastfind code that aaronl wrote. please do not make the mistake that i made
in reassigning the bug to aaronl. blake wrote the code.

Comment 9

[Michael Clackler]

Attachment: patch to possibly fix

I'm not sure if this will fix the problem, but I noticed there was no check to
verify "ds" was valid before it was called.  

Following the TalkBack reports, they all seem to point to a line calling ds
right after it is defined (if I'm reading the reports right).  In other areas
of the code using the same method, there is always check to verify the variable
is valid before it is used.  I copied the check used in this patch from these
areas.

There was a second area in the file that had the same "problem" that is
included in the patch.

Comment 10

[Michael Clackler]

Some of the talkBack reports also mention some crashes during/after opening new
tabs.  The patch in bug 264562 will probably solve this problem.

Comment 11

[timeless]

[e-mail]: your patch isn't very graceful (although it indeed
should deal w/ the crash). note that later in the code, there's a call to play a
sound on not found, which should probably be reached.

Comment 12

[Michael Clackler]

Attachment: patch with call to PlayNotFoundSound

This patch includes a call to play the not found sound as timeless suggested.

Comment 13

[Michael Clackler]

Attachment: same patch diff -up8

This is the same patch as the last one, only using -up8 options as requested

Comment 14

[Michael Clackler]

Attachment: cleaner patch with error logging

This patch is the same as patch #1 but uses NS_ENSURE_TRUE to log the error
before escaping at the advice of mconnor since we really should not be failing
here.

This patch doesn't solve the root problem of why it is failing (probably focus
related), but will prevent the browser from crashing when the failing state is
reached and log the failure for future debugging.

In the future if the focus issues get resolved, it would still be a good idea
to perform the error checks in this patch.

Comment 15

[Jay Patel [:jay]]

Adding FFTrunk to summary since this continues to be a topcrasher on the
FirefoxTrunk as well.  Any progress on the patch?  Anyone wanna r=, sr= this
thing to see if the crash goes away?

Here is a recent FirefoxTrunk incident:
Incident ID: 3327370
Stack Signature	nsTypeAheadFind::Find 331e8ebe
Product ID	FirefoxTrunk
Build ID	2005012606
Trigger Time	2005-01-27 09:33:55.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	firefox.exe + (003d74e2)
URL visited	
User Comments	
Since Last Crash	281 sec
Total Uptime	281 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/toolkit/components/typeaheadfind/src/nsTypeAheadFind.cpp,
line 805
Stack Trace 	
nsTypeAheadFind::Find 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/toolkit/components/typeaheadfind/src/nsTypeAheadFind.cpp,
line 805]
XPTC_InvokeByIndex 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2034]
XPC_WN_CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line
1293]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line
3565]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line
1313]
nsXPCWrappedJSClass::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1339]
nsXPCWrappedJS::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
SharedStub 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsEventListenerManager::HandleEventSubType 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1519]
nsEventListenerManager::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1596]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2035]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2054]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2054]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2054]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2054]
nsXULElement::HandleChromeEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2720]
nsGlobalWindow::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 928]
nsDocument::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocument.cpp,
line 3837]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 2028]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 5905]
PresShell::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 5761]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2377]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2151]
HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 174]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1103]
nsWindow::DispatchKeyEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 3045]
nsWindow::OnChar 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 3280]
nsWindow::OnKeyDown 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 3132]
nsWindow::ProcessMessage 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 4022]
nsWindow::WindowProc 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1389]
USER32.dll + 0x2a420 (0x77e3a420)
USER32.dll + 0x4605 (0x77e14605)
USER32.dll + 0xa7ba (0x77e1a7ba)
nsAppStartup::Run 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 146]
main 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/browser/app/nsBrowserApp.cpp,
line 60]
KERNEL32.DLL + 0x2893d (0x7c59893d)

Comment 16

[Thomas Rutter]

This looks like this is a duplicate of bug #274321, though this one has more
activity than the former.

I have the incident IDs of two crashes which happened when using the Find Toolbar

TB3335927M
TB3416424M

Comment 17

[Thomas Rutter]

For me, this bug happens under the same circumstances as bug #270546, for which
I added some good steps to reproduce in bug #270546 comment #5.

Comment 18

[sairuh (rarely reading bugmail)]

*** Bug 274321 has been marked as a duplicate of this bug. ***

Comment 19

[sairuh (rarely reading bugmail)]

*** Bug 270546 has been marked as a duplicate of this bug. ***

Comment 20

[Asaf Romano (gone)]

Comment on attachment 170690 [details] [diff] [review]
cleaner patch with error logging

Well, that won't fix the find-doesn't-work problem

Comment 21

[daneel]

TB4038251X, still happens with Firefox Trunk 2005022806

Comment 22

[Ger Teunis]

(In reply to comment #21)
> TB4038251X, still happens with Firefox Trunk 2005022806

Same here all the time.
I think it might be related to the tab focus error using Find in
bug#274557

Comment 23

[Asaf Romano (gone)]

Should be fixed in the next build, please test (bug 278544).

Comment 24

[Boris Zbarsky [:bzbarsky]]

ccing some drivers.  It seems that the Firefox find implementation is basically
unowned (I certainly don't see blake doing his module owner duties here).  In my
opinion, it would make a lot more sense to move this code somewhere into core
(especially since it uses private layout interfaces), where it could be
maintained by people who perhaps care whether Firefox crashes or not...

Comment 25

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 170690 [details] [diff] [review]
cleaner patch with error logging

sr=bzbarsky.  I see no reason why this code is expecting that do_QueryReferent
on an nsWeakPtr will always return non-null.  In fact, the PRECISE point of
nsWeakPtr is to return null as needed.	It's not clear to me whether the code
should return NS_OK when there's no currently-focused content window, though...
That may be better (with an NS_WARNING about the lack of a window).

Requesting review from the owner of this code, and keeping my fingers crossed.

Comment 26

[Benjamin Smedberg]

Comment on attachment 170690 [details] [diff] [review]
cleaner patch with error logging

I can land this Monday, if nobody else does it first.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Fix checked in.  Michael, thank you very much for the patch, and my deepest
apologies for the disorganization and lack of respect you had to deal with. 
Thank you for being patient in the face of it!

Comment 28

[Jesse Ruderman]

Comment 20 says the patch only fixed the crash, not the not-working that is also
in this bug's summary.  Has a new bug been filed for the not-working?

Comment 29

[Boris Zbarsky [:bzbarsky]]

I believe bug 278544 purported to fix that (per comments in that bug and comment
23 here).

Comment 30

[earthsound]

is the patch for this bug incorporated into 1.0.2? 

I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050317 Firefox/1.0.2 & see this crash often, mostly recently:

TB4850163Z

It seems that that crash, along with the other almost 1300 crashes in
talkback-public.mozilla.org, since March 15, for nsTypeAheadFind::Find: that Jay
mentions in comment #7 would indicate that this is still happening...

see
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsTypeAheadFind%3A%3AFind&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid
for latest talkback data for this crash...

Comment 31

[Boris Zbarsky [:bzbarsky]]

> is the patch for this bug incorporated into 1.0.2? 

No.  If it were, there would be a keyword to that effect.  I'm not sure drivers
are taking patches of this sort on branch at this point, but feel free to
nominate it (via the approval flag on the patch)....

Comment 32

[Asaf Romano (gone)]

Tweaking summary to clarify what was fixed here.

Comment 33

[Jay Patel [:jay]]

Reopening to nominate for Aviary branch.  This has become more visible with
recent branch builds.  If we think this patch is low risk, I think we should get
it in FF 1.0.3.

I have had a crashes with this signature, my most recent being:
Incident ID: 5000727
Stack Signature	nsTypeAheadFind::Find 451e6eb3
Product ID	Firefox10
Build ID	2005040817
Trigger Time	2005-04-11 01:22:10.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (003f1855)
URL visited	afterdawn.net?
User Comments	type ahead find... doesn't get past first letter.
Since Last Crash	5830 sec
Total Uptime	69651 sec
Trigger Reason	Access violation
Source File, Line No.
d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/typeaheadfind/src/nsTypeAheadFind.cpp,
line 810
Stack Trace 	
nsTypeAheadFind::Find 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/typeaheadfind/src/nsTypeAheadFind.cpp,
line 810]
XPTC_InvokeByIndex 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2034]
XPC_WN_CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1641]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 949]
js_Interpret 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 2993]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 966]
js_InternalInvoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1043]
JS_CallFunctionValue 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 3698]
nsJSContext::CallEventHandler 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1297]
nsJSEventListener::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsEventListenerManager::HandleEventSubType 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1436]
nsEventListenerManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1516]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2841]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2860]
nsGenericElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 1993]
nsHTMLInputElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1405]
PresShell::HandleEventInternal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6059]
PresShell::HandleEventWithTarget 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5984]
nsTextControlFrame::FireOnInput 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/forms/src/nsTextControlFrame.cpp,
line 3038]
nsTextInputListener::EditAction 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/forms/src/nsTextControlFrame.cpp,
line 497]
nsEditor::NotifyEditorObservers 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/editor/libeditor/base/nsEditor.cpp,
line 1632]
nsPlaintextEditor::TypedText 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/editor/libeditor/text/nsPlaintextEditor.cpp,
line 501]
nsPlaintextEditor::HandleKeyPress 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/editor/libeditor/text/nsPlaintextEditor.cpp,
line 480]
nsTextEditorKeyListener::KeyPress 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/editor/libeditor/text/nsEditorEventListeners.cpp,
line 251]
DispatchToInterface 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 127]
nsEventListenerManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1524]
nsGenericElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 1963]
nsHTMLInputElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1405]
PresShell::HandleEventInternal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6084]
PresShell::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5921]
nsViewManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2280]
nsViewManager::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2066]
HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsView.cpp,
line 77]
nsWindow::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1067]
nsWindow::DispatchKeyEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 2978]
nsWindow::OnChar 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 3162]
nsWindow::ProcessMessage 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 3878]
nsWindow::WindowProc 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1349]
USER32.dll + 0x8709 (0x77d48709)
USER32.dll + 0x87eb (0x77d487eb)
USER32.dll + 0x89a5 (0x77d489a5)
USER32.dll + 0x89e8 (0x77d489e8)
nsAppShell::Run 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsAppShell.cpp,
line 159]
nsAppShellService::Run 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 495]
main 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 58]
kernel32.dll + 0x16d4f (0x7c816d4f)

Comment 34

[Boris Zbarsky [:bzbarsky]]

Jay, I'm not sure why you reopened the bug instead of just requesting approval
on the patch... the bug is absolutely FIXED on trunk.

Note that the patch _did_ have an approval request for 1.0.3 and drivers denied
approval already.

Comment 35

[Jay Patel [:jay]]

Sorry Boris... returning to Fixed.  BUT we should consider getting this in since
the patch looks pretty simple and this is a top 30 crasher in Firefox 1.0.x.

Comment 36

[Jay Patel [:jay]]

Also worth noting is that this crash looks like somewhat of a regression since
1.0.  I am seeing a lot of crashes in 1.0.x data for builds from 2005:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsTypeAheadFind%3A%3AFind&vendor=All&product=Firefox10&platform=All&buildid=2005&sdate=&stime=&edate=&etime=&sortby=build

Versus just a few crashes from 2004 (mostly Firefox 1.0):
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=+nsTypeAheadFind%3A%3AFind&vendor=All&product=Firefox10&platform=All&buildid=2004&sdate=&stime=&edate=&etime=&sortby=build

Hopefully that is enough data to convince drivers to get this fix onto the
Aviary branch.

Comment 37

[Chase Phillips]

per drivers meeting, setting blocking-aviary1.0.3+

Comment 38

[Chase Phillips]

Comment on attachment 170690 [details] [diff] [review]
cleaner patch with error logging

approval-aviary1.0.3+ by chase/drivers for the aviary1.0.1 branch.  Based on
trunk performance, this patch should work well on the branch.

Comment 39

[Chase Phillips]

Comment on attachment 170690 [details] [diff] [review]
cleaner patch with error logging

Landed on the Aviary1.0.1 branch.

Checking in toolkit/components/typeaheadfind/src/nsTypeAheadFind.cpp;
/cvsroot/mozilla/toolkit/components/typeaheadfind/src/nsTypeAheadFind.cpp,v 
<--  nsTypeAheadFind.cpp
new revision: 1.1.2.9.2.1; previous revision: 1.1.2.9
done

Comment 40

[Chase Phillips]

fixed-aviary1.0.3

Comment 41

[sairuh (rarely reading bugmail)]

will monitor the talkback reports to see if the frequency of this crasher goes
down (starting with last night's branch builds).

Comment 42

[Worcester12345]

(In reply to comment #41)
> will monitor the talkback reports to see if the frequency of this crasher goes
> down (starting with last night's branch builds).

Assuming it did.