Closed
Bug 280084
Opened 20 years ago
Closed 19 years ago
FF101 nsAutoComplete crash on entering URL [@ nsAutoCompleteController::HandleEnter]
Categories
(Toolkit :: Form Manager, defect)
Toolkit
Form Manager
Tracking
()
VERIFIED
FIXED
People
(Reporter: myob87, Assigned: bryner)
References
Details
(5 keywords)
Crash Data
Attachments
(2 files, 1 obsolete file)
7.62 KB,
patch
|
jst
:
review+
shaver
:
superreview+
brendan
:
approval-aviary1.0.1+
|
Details | Diff | Splinter Review |
1.64 KB,
patch
|
dveditz
:
review+
bugs
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8b) Gecko/20050119 Firefox/1.0+ Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8b) Gecko/20050119 Firefox/1.0+ A random crash will occur on around the tenth time the address bar is used on BeOS Firefox, with the following stack crawl being obtained: From my observations, it seems to affect never-visted before URL's being entered than previously visited URL's loading symbols segment violation occurred nsAutoCompleteController::HandleEnter(int *): HandleEnter__24nsAutoCompleteControllerPi: +001d efacd631: * 088b movl (%eax), %ecx firefox-bin:sc frame retaddr fcff9c78 ee952248 XPTC_InvokeByIndex + 00000054 fcff9ca4 efe460b2 XPCWrappedNative::CallMethod(XPCCallContext &, XPCWrappedNative::CallMode) + 00000e5e fcff9ed4 efe4c9f4 XPC_WN_CallMethod(JSContext *, JSObject *, unsigned int, long *, long *) + 000000d0 fcff9f94 ee826337 js_Invoke + 00000923 fcffa084 ee82f325 js_Interpret + 000080b1 fcffa274 ee8263a9 js_Invoke + 00000995 fcffa354 ee8265f7 js_InternalInvoke + 000000c3 fcffa3f4 ee7f601a JS_CallFunctionValue + 00000036 fcffa434 ef33abdd nsJSContext::CallEventHandler(JSObject *, JSObject *, unsigned int, long *, long *) + 00000119 fcffa494 ef37973e nsJSEventListener::HandleEvent(nsIDOMEvent *) + 0000060a fcffa5c4 ef2f66f6 nsXBLPrototypeHandler::ExecuteHandler(nsIDOMEventReceiver *, nsIDOMEvent *) + 00001652 fcffa914 ef2f271f nsXBLKeyEventHandler::HandleEvent(nsIDOMEvent *) + 0000012b fcffa964 ef22b0d7 nsEventListenerManager::HandleEventSubType(nsListenerStruct *, nsIDOMEvent *, nsIDOMEventTarget *, unsigned int, unsigned int) + 000002e3 fcffaa74 ef22b4ae nsEventListenerManager::HandleEvent(nsPresContext *, nsEvent *, nsIDOMEvent **, nsIDOMEventTarget *, unsigned int, nsEventStatus *) + 0000035a fcffab04 ef305503 nsXULElement::HandleDOMEvent(nsPresContext *, nsEvent *, nsIDOMEvent **, unsigned int, nsEventStatus *) + 00000e7f fcffacc4 ef3053da nsXULElement::HandleDOMEvent(nsPresContext *, nsEvent *, nsIDOMEvent **, unsigned int, nsEventStatus *) + 00000d56 fcffae84 ef3053da nsXULElement::HandleDOMEvent(nsPresContext *, nsEvent *, nsIDOMEvent **, unsigned int, nsEventStatus *) + 00000d56 fcffb044 ef1fb363 nsGenericElement::HandleDOMEvent(nsPresContext *, nsEvent *, nsIDOMEvent **, unsigned int, nsEventStatus *) + 0000059f fcffb154 ef27e432 nsHTMLInputElement::HandleDOMEvent(nsPresContext *, nsEvent *, nsIDOMEvent **, unsigned int, nsEventStatus *) + 0000040e fcffb2e4 ef02169f PresShell::HandleEventInternal(nsEvent *, nsIView *, unsigned int, nsEventStatus *) + 0000031b fcffb344 ef0212a6 PresShell::HandleEvent(nsIView *, nsGUIEvent *, nsEventStatus *, int, int &) + 00000612 fcffb3b4 ef3306db nsViewManager::HandleEvent(nsView *, nsGUIEvent *, int) + 000000f7 fcffb4e4 ef32ff36 nsViewManager::DispatchEvent(nsGUIEvent *, nsEventStatus *) + 00000b22 fcffb584 ef329dcc HandleEvent(nsGUIEvent *) + 00000048 fcffb5b4 efdbb6fb nsWindow::DispatchEvent(nsGUIEvent *, nsEventStatus &) + 00000057 fcffb5f4 efdbb78c nsWindow::DispatchWindowEvent(nsGUIEvent *) + 00000038 fcffb624 efdb9762 nsWindow::DispatchKeyEvent(unsigned int, unsigned int, unsigned int) + 0000010e fcffb6a4 efdb962d nsWindow::OnKeyDown(unsigned int, char const *, long, unsigned int, unsigned int, long) + 000002c9 fcffb6e4 efdbc1ff nsWindow::CallMethod(MethodInfo *) + 0000053b fcffb7c4 efdaff19 nsAppShell::Run(void) + 000000d5 fcffb804 efacae0d nsAppStartup::Run(void) + 00000029 fcffb834 8000d1a1 xre_main(int, char **, nsXREAppData const *) + 00001afd fcffc214 800078bd main + 00000029 fcffc244 80007585 _start + 00000061 firefox-bin: This will happen eventually every time the browser is used. Reproducible: Always Steps to Reproduce: 1. Browse randomly, use the URL bar frequently Actual Results: Firefox will eventually crash Expected Results: Firefox should not crash.
Comment 2•19 years ago
|
||
This appears to be on all platforms according to Talkback data. Just noticed this topcrasher in the latest Firefox 1.0.1 branch reports. Probably too late for that release, but wanted to see if we can get some traction on this quickly. It looks like it could be a potential topcrasher for 1.0.1. There were only about 300 crashes for all branch build from 2004 (which included all 1.0 versions)...and I already see about 70 with 2005 builds: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsAutoCompleteController%3A%3AHandleEnter&vendor=All&product=Firefox10&platform=All&buildid=2005&sdate=&stime=&edate=&etime=&sortby=bbid Marking topcrash+ to see if we can figure this out soon...
Comment 3•19 years ago
|
||
Here is a recent crash with today's build: Incident ID: 3889532 Stack Signature nsAutoCompleteController::HandleEnter 1d583964 Product ID Firefox10 Build ID 2005022304 Trigger Time 2005-02-23 12:04:34.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module firefox.exe + (003ee42b) URL visited http://www.paypal.com/ User Comments Whenever I attempt to go to paypal.com, the browser crashes. Since Last Crash 8 sec Total Uptime 5236 sec Trigger Reason Access violation Source File, Line No. d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp, line 229 Stack Trace nsAutoCompleteController::HandleEnter [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp, line 229] 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 1287] 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] nsXBLPrototypeHandler::ExecuteHandler [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeHandler.cpp, line 463] nsXBLKeyEventHandler::HandleEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLEventHandler.cpp, line 146] 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 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsGenericElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 1915] 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::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) Looks like this is either a startup crash or delayed crash related to upgrading from 1.0 to 1.0.1 from looking at the latest comments. Might be extensions related, but not sure. Still trying to reproduce.
Comment 4•19 years ago
|
||
i have the problem in the nl-NL build also talk back id: TB3904877H TB3904113H TB3903990M TB3903754M i think this is a blocker for 1.0.1
Severity: major → blocker
Comment 5•19 years ago
|
||
(In reply to comment #4) > i have the problem in the nl-NL build also > > i think this is a blocker for 1.0.1 Tim: did you install into a fresh directory, or over an existing build? If the latter was it a trunk build? This high crash rate worries me, and it has been too easily dismissed as an artifact of installing over a trunk build. There *was* a change to autocomplete in 1.0.1, though it doesn't appear to be involved with the crash location.
Comment 6•19 years ago
|
||
The stacks show we're crashing dereferencing mInput. nsAutoCompleteController::HandleText has a check for mInput being null before it is dereferenced, a fix for crash bug 193544 (when used with an IME). The SetInput() routine has comments and checks that imply it *is* sometimes set to null. But all of the other event handlers simply dereference mInput, assuming it's got to be good if we're getting events for it. The rest of the code assumes that if we're getting events for it mInput must exist. It'd be simple enough to stop the crashes by adding some NS_ENSURE_TRUE's, but I'm not sure if we need to do something about the unexpected state or even how we got there.
Assignee: firefox → bryner
Component: Menus → Form Manager
Comment 7•19 years ago
|
||
I still have not been able to reproduce this. I installed 1.0.1 over a Trunk build and did not crash with a new profile. I'll try a few different things today based on Talkback comments, but adding helpwanted keyword to see if others can figure out a way to repro. Dan: With the release almost out the door, should we consider this a blocker? Unless someone can say for sure they know what is causing this and provide a patch that we can consider "safe"...we should probably change the severity.
Keywords: helpwanted
Comment 8•19 years ago
|
||
Is anyone that's seeing this enabling any hidden prefs like browser.urlbar.autoFill or installing extensions that would alter URLbar behavior?
Comment 10•19 years ago
|
||
Null defense (note after *_retval setting where necessary) plus a fix to an uninitialized variable bug flagged by Coverity, which may or may not be relevant. Note that SetInput is called with a null argument according to lxr. /be
Attachment #175512 -
Flags: superreview?(shaver)
Attachment #175512 -
Flags: review?(jst)
Attachment #175512 -
Flags: approval-aviary1.0.1+
Comment 11•19 years ago
|
||
dveditz, feel free to review too (I picked jst cuz he's around, and he touched the file; bryner would've been good too but he's unavailable). We want to respin fast with this prophylactic fix to what seem like potential null dereferences, and of course the uninitialized variable bug found by Coverity and patched per your fix that we discussed earlier tonight. /be
Comment 12•19 years ago
|
||
Comment on attachment 175512 [details] [diff] [review] diff -w of proposed branch patch Oops, wrong patch -- right one coming right up. /be
Attachment #175512 -
Attachment is obsolete: true
Attachment #175512 -
Flags: superreview?(shaver)
Attachment #175512 -
Flags: review?(jst)
Attachment #175512 -
Flags: approval-aviary1.0.1+
Comment 13•19 years ago
|
||
Attachment #175514 -
Flags: superreview?(shaver)
Attachment #175514 -
Flags: review?(jst)
Attachment #175514 -
Flags: approval-aviary1.0.1+
Comment 14•19 years ago
|
||
Comment on attachment 175514 [details] [diff] [review] diff -w of proposed branch patch r=jst
Attachment #175514 -
Flags: review?(jst) → review+
Comment on attachment 175514 [details] [diff] [review] diff -w of proposed branch patch sr=shaver. Hippocrates would be proud, it can clearly do no harm.
Attachment #175514 -
Flags: superreview?(shaver) → superreview+
Comment 16•19 years ago
|
||
Checking in nsAutoCompleteController.cpp; /cvsroot/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp,v <-- nsAutoCompleteController.cpp new revision: 1.15.2.1.2.5.2.2; previous revision: 1.15.2.1.2.5.2.1 done I'll leave the trunk merge to someone else. At this point we'll be getting much better talkback from the release, but it would be good to patch the trunk soon to match the branch. I wrote: > Note that SetInput is called with a null argument according to lxr. Specifically, http://lxr.mozilla.org/mozilla/source/toolkit/components/satchel/src/nsFormFillController.cpp#971 called from Blur, Submit, and Unload methods in the same file, among other places. I didn't study the whole system, but it sure seems as though we could have a blur (or something) nulling mInput in nsAutoCompleteController. Leaving assigned to bryner, who could probable shed some light here, pending the return of hewitt. /be
Comment 17•19 years ago
|
||
I just downloaded Firefox 1.0.1 and did a "dumb user" install. Over the top of an existing install. Getting this error when trying to go to http://www.trademe.co.nz See TB3922403Q, TB3922384X and TB3922362K. They are all about the same thing, Access Violation in d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp, line 229
Comment 18•19 years ago
|
||
Hmmm, it seems that entering any URL via the keyboard causes a crash, while clicking links works fine. Autocomplete seems to be the problem area.
Comment 19•19 years ago
|
||
adding fixed-aviary1.0.1 keyword due to the checkin in comment 16. (pls do remove that kw, though, if that checkin isn't a good enough fix for this on the 1.0.1 branch.)
Keywords: fixed-aviary1.0.1
Comment 20•19 years ago
|
||
Was the checkin from Comment #16 before or after the "official" release of 1.0.1?
Comment 21•19 years ago
|
||
Comment on attachment 175514 [details] [diff] [review] diff -w of proposed branch patch Looks good to me too, though I'm curious why the original code checked for a non-empty error string before believing the RESULT_FAILURE value it got back from search. dgk: check the dates. Patch comments are from today, all after the release.
Comment 22•19 years ago
|
||
Sorry about the dates, I keep getting confused as it's 2005-02-05 21:24 NZST where I am.
Comment 23•19 years ago
|
||
I can reproduce a variation of the problem with 2005-02-24-22 where I can't hit enter after entering an URL. Get following Javascript message :- Error: uncaught exception: [Exception... "Cannot find interface information for parameter arg 0 [nsIAutoCompleteController.input]" nsresult: "0x80570006 (NS_ERROR_XPC_CANT_GET_PARAM_IFACE_INFO)" location: "JS frame :: chrome://global/content/bindings/autocomplete.xml :: detachController :: line 254" data: no]
Comment 24•19 years ago
|
||
Removing keyword fixed-aviary1.0.1 since, per comment #21, this wasn't fixed in time for the 1.0.1 release (and there is no fixed-aviary1.0.2 keyword).
Keywords: fixed-aviary1.0.1
Comment 25•19 years ago
|
||
Build 1.0.2 2005-02-25-01 is the same as Comment #23
Comment 26•19 years ago
|
||
(In reply to comment #5) > (In reply to comment #4) > > i have the problem in the nl-NL build also > > > > i think this is a blocker for 1.0.1 > > Tim: did you install into a fresh directory, or over an existing build? If the > latter was it a trunk build? This high crash rate worries me, and it has been > too easily dismissed as an artifact of installing over a trunk build. > > There *was* a change to autocomplete in 1.0.1, though it doesn't appear to be > involved with the crash location. sorry for the late reaction: i did do both way's of in stalling and still have the crash
Comment 27•19 years ago
|
||
Ok, yesterday i tested it with a install in the same dir as the previus one => no go. Then i unstall true the windows software screen and reinstall the version => no go. Today i also deleted all the left over files in the installation dir after the uninstall and then reinstalled => problem solved. even with my old profile.
Comment 28•19 years ago
|
||
Tim: Do you remember exactly what files were left in the installation directory before you wiped it clean? Can you reproduce this after installing into a clean directory?
Assignee | ||
Comment 29•19 years ago
|
||
Anyone who is seeing this currently: do you have both an autocomplete.xpt and a browser.xpt file in the "components" directory (under the installation directory)?
Comment 30•19 years ago
|
||
I have not been able to crash (although I did see the JS errors), and I don't have the autocomplete.xpt file in my components directory (just browser.xpt).
Comment 31•19 years ago
|
||
i have putt the deleted files back in this order: AccessibleMarshal.dll components.ini mozctl.dll mozctlx.dll default.ini folders: -chrome -components -defaults -extensions -grefrefs -plugins and after this one it happened again. after that i wanted to reproduce it but now i don't get it anymore (probably deleted a file permantly by accident)
Comment 32•19 years ago
|
||
Because of my undying faith in bryner (you rock, man) and from dgk's most recent comments, I gather that the combo of autocomplete.xpt and browser.xpt is causing this problem. Neither jay, cbeard, and myself see this combo in our installations, so I googled about. I saw that autocomplete.xpt is in a SuSE 0.10 Firefox package. I've asked Jay to try installing 0.10.1 into a new directory, then to install 1.0.1 on top of that. It's a shot in the dark, but maybe that will elicit this bug.
Comment 33•19 years ago
|
||
(In reply to comment #32) > Because of my undying faith in bryner (you rock, man) and from dgk's most recent > comments, I gather that the combo of autocomplete.xpt and browser.xpt is causing > this problem. Neither jay, cbeard, and myself see this combo in our > installations, so I googled about. I saw that autocomplete.xpt is in a SuSE > 0.10 Firefox package. I've asked Jay to try installing 0.10.1 into a new > directory, then to install 1.0.1 on top of that. It's a shot in the dark, but > maybe that will elicit this bug. i am sorry but i have both files in the dir and don't see the problem anymore
Comment 34•19 years ago
|
||
hmm after uninstall an reinstall in a dir with leftovers from the previuos one it happened again.
Assignee | ||
Comment 35•19 years ago
|
||
I was able to reproduce this crash as follows: Install a zip build of firefox 1.0 Create a new profile and launch the newly-installed build Install 1.0.1 using the installer, into the same directory Launch using the profile previously created Type into the urlbar So, I believe this is something users may hit if they've ever installed a zip build into the install directory, because it leaves an autocomplete.xpt typelib for the older version of the interface. Then at runtime, we end up calling the wrong method. What can we do about it? Long-term, we should either discontinue the zip builds or make them use linked xpt files. Or make the installer refuse to install into a directory that's been used by a zip build, if we can determine that. For now, though, let's just nuke autocomplete.xpt from the installer so that the interface definition from browser.xpt is used.
Comment 36•19 years ago
|
||
So I was able to reproduce this. Chase noticed that all zipped builds include the autocomplete.xpt file (along with a lot of other .xpt files). So this is what I did: 1. Installed the zipped 0.10.1 (1.0 PR) 2. Installed 1.0.1 with the installer over the 0.10.1 install 3. Started 1.0.1 4. No home page was loaded (just a blank window) 5. Started typing into the url bar and pressed enter Here is my incident: Incident ID: 3927322 Stack Signature nsAutoCompleteController::HandleEnter 1d583964 Email Address jay@mozilla.org Product ID Firefox10 Build ID 2005022304 Trigger Time 2005-02-25 03:38:07.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module firefox.exe + (003ee42b) URL visited installed 1.0.1 over a zipped 0.10.1 (1.0 pr1) User Comments installed 1.0.1 over a zipped 0.10.1 (1.0 pr1) Since Last Crash 63191 sec Total Uptime 63191 sec Trigger Reason Access violation Source File, Line No. d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp, line 229 Stack Trace nsAutoCompleteController::HandleEnter [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp, line 229] 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 1287] 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] nsXBLPrototypeHandler::ExecuteHandler [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeHandler.cpp, line 463] nsXBLKeyEventHandler::HandleEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLEventHandler.cpp, line 146] 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 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsGenericElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 1915] 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::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 37•19 years ago
|
||
(In reply to comment #34) > hmm after uninstall an reinstall in a dir with leftovers from the previuos one > it happened again. What's your process for "starting over"? What version did you start with? Was it a compressed build? And for 1.0.1, are you uncompressing on top of that with another .zip build? Or are you installing the .exe on top of an uncompressed zip build folder?
Assignee | ||
Comment 38•19 years ago
|
||
Attachment #175533 -
Flags: superreview?(benjamin)
Attachment #175533 -
Flags: review?(dveditz)
Comment 39•19 years ago
|
||
Comment on attachment 175533 [details] [diff] [review] patch r=dveditz This solves it for me, though I'm a bit worried about what other extraneous junk is left over from the old zip builds that could cause problems. Between 1.0 and 1.0.1 this is the only one with a changed interface. There's an *additional* docshell interface in 1.0.1, but it should find that in browser.xpt
Attachment #175533 -
Flags: review?(dveditz) → review+
Comment 40•19 years ago
|
||
ok , i did a serie of installations with and without the autocomplete. i can confirm that it is the problem. but if you install 1.0.1 into a dir with autocomple and you have the problem, and you delete then the autocomple file , FF will not react on anything you type in the url bar. Even after a reinstall. You have to clear the whole dir after a uninstall and then reinstall FF again. why doesn't the uninstaller delete the components dir?
Comment 41•19 years ago
|
||
(In reply to comment #40) > why doesn't the uninstaller delete the components dir? i mean why doesn't he just delete it even when there are files left inside.
Comment 42•19 years ago
|
||
Comment on attachment 175533 [details] [diff] [review] patch sr=ben@mozilla.org
Attachment #175533 -
Flags: superreview?(benjamin) → superreview+
Assignee | ||
Comment 43•19 years ago
|
||
checked in on trunk and 1.0.1 branch
Comment 44•19 years ago
|
||
If cs-CZ l10n Firefox 1.0.1 build wasn't released yet, will be released with this fix included?
Comment 45•19 years ago
|
||
(In reply to comment #44) > If cs-CZ l10n Firefox 1.0.1 build wasn't released yet, will be released with > this fix included? would be nice for the nl-NL build too
Comment 46•19 years ago
|
||
bryner: You marked this 'fixed-aviary1.0.1', but this clearly isn't fixed for the variants of 1.0.1 that have already been released. Are we planning to respin all the existing 1.0.1 releases? (The alternative -- having only some of the 1.0.1 releases contain this patch -- is just as crazy).
Comment 47•19 years ago
|
||
The right thing to do is 1.0.2, so let's do that. We need to fix xpt linking vs. zip builds as bryner said. Better, we should beef up the system so the hazard of two .xpt files fighting over one nsIFoo interface *name* (dveditz changed the uuid, which was good for C++, but doesn't help JS) is detected and corrected. There may be another moral here: always add new interface members at the end, even when changing the uuid. It's crashier and clearer when Things Go Wrong. Bryner rocks, cmp rocks, jay rocks. Thanks to them, and also to David and Tim for crucial testing feedback. /be
Comment 48•19 years ago
|
||
Filed bug 283670 on the Coverity-detected uninitialized rowCount variable bug. /be
Comment 49•19 years ago
|
||
*** Bug 283588 has been marked as a duplicate of this bug. ***
Comment 50•19 years ago
|
||
I know, the bug is fixed....but deleting autocomplete.xpt fixed everything for me as well. Good work.
Status: RESOLVED → VERIFIED
Comment 51•19 years ago
|
||
See bug 283691 for a spin-off to robusticate xpconnect or xpcom's typelib jazz, or both, to cope with warring .xpt files. /be
Comment 52•19 years ago
|
||
fixed-aviary1.0.1 already set, but retroactively setting blocking-aviary1.0.1.
Flags: blocking-aviary1.0.1+
Comment 53•19 years ago
|
||
O. K. Took a read of this page. Currnetly using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.2 from today. since Fen 5th 2005 has used the Trunks till the 22nd then getting the 1.0.1 on the 22nd and having a system crash with it. Did a clean install and all was well. Some extensions do not wish to work, but that is the extension writers responsibility to up the version numbers to the later trunk/aviary. So far this has been WFM and the only issue are extensions. It seems the form manager I had no issues with. At least noticeable. It did auto fill when I needed so am not too sure what the problems are here. Windows XP Pro Build 2600 with SP2 and several SP3 Files. I know someone will tell me there is no SP3 but tell that to the files installed and microsoft. My Belarc Advisor just gets the information from that. Maybe this is the Trunk that had the issue and os specific, since I had not seen the Form Problem even back to the 5th of Feb.
Comment 54•19 years ago
|
||
*** Bug 284051 has been marked as a duplicate of this bug. ***
Comment 55•19 years ago
|
||
*** Bug 284317 has been marked as a duplicate of this bug. ***
Comment 56•19 years ago
|
||
*** Bug 283634 has been marked as a duplicate of this bug. ***
Comment 57•19 years ago
|
||
*** Bug 284318 has been marked as a duplicate of this bug. ***
Comment 58•19 years ago
|
||
FF 1.5 is still showing crashes in nsAutoCompleteController::HandleEnter, on all platforms, according to Talkback.
Updated•19 years ago
|
QA Contact: bugzilla → form.manager
Comment 59•19 years ago
|
||
TB14022778W not fixed
Updated•16 years ago
|
Product: Firefox → Toolkit
Updated•13 years ago
|
Crash Signature: [@ nsAutoCompleteController::HandleEnter]
Comment hidden (spam) |
Comment hidden (spam) |
You need to log in
before you can comment on or make changes to this bug.
Description
•