Closed Bug 184202 Opened 22 years ago Closed 22 years ago

Firebird autocomplete crash - MFB06 [@ nsTreeSelection::SetCurrentIndex] [@ nsTreeRange::Invalidate] select form field

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: nate, Assigned: hewitt)

References

Details

(Keywords: crash, topcrash)

Crash Data

Attachments

(8 files, 1 obsolete file)

Test case to cause Phoenix to crash from form autocompletion
913 bytes, text/html
Details
Stack trace of crash caused by previous attachment
34.33 KB, text/plain
Details
a version that compiles
604 bytes, patch
janv
: review-
janv
: superreview-
Details | Diff | Splinter Review
additional gdb info per comment #10
565 bytes, text/plain
Details
Error message I received
3.07 KB, image/gif
Details
valgrind output for the crash
5.21 KB, text/plain
Details
more valgrind
4.94 KB, text/plain
Details
Patch based on bug 190447
2.85 KB, patch
janv
: review+
jag+mozilla
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4 When using form autocomplete via mouse or keyboard, Phoenix often (multiple times per day) crashes. I reported this as bug #181094 for Mozilla (including a reproducible test case and a stack trace), but it's been a week and I've gotten no response. But recently I've been wondering if this might be a Phoenix bug. Based on other people's reports, the bug is multiplatform. I've found it in the 0.4 release, and in the nightlies. It's been a hard bug for me to debug under Linux, since the crash seems to grab the keyboard and freeze the window manager. I was hoping I could solve it myself, but I'm not making much progress. I think the problem is a runaway pointer, since there seem to be many different but related ways of causing the crash, although it may be a threading issue. The problem seems to be related to forms appearing in newly created windows. Stack trace and test case to follow. Reproducible: Always Steps to Reproduce:
This test case should be saved to a local drive before testing. If you try to run it in place on the bugzilla server, the form submissions necessary to reproduce the bug will confuse the bugzilla server. Almost all the details of this test case are arbitrary, other than the use of autocomplete and the creation of and switching between windows. The use of "#" as a target is merely a convenience to get the test case down to one file.
This is a Linux stack trace from the crash caused by the autocomplete bug. It is consistent for the test case I gave, but the deepest functions seem to vary with other similar cases. Contact tom at redpepperracing for access to one. This stack trace was difficult to capture, since the crash freezes the window manager until Phoenix exits. I found it necessary to start Phoenix from a virtual terminal using "DISPLAY=:0.0 phoenix -g 1 > phoenix.out 2>&1" and run the debugger blind using "tail -f phoenix.out" in another virtual terminal. If you know of a better way to do this with gdb, please tell me for future use.
I can confirm what Mr. Kurz reported, that this is a reproducible bug affecting Phoenix, since at least 0.4, and it has not been resolved in 0.5. The bug also affects Phoenix under Windows XP. It seems to happen more frequently when multiple windows are open.
we have several similar bugs here for one and the same problem: bug #181094 bug #179821 bug #178395 and bug #178322 As this bug here seem to be the one containing the most valuable information with useful test-case and back-trace I would suggest to duplicate the above mentioned bugs and to focus on this one. Changed state to "New" (as we obviously have enough confirmations on this) and added keyword "Crash"...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Problems related to this bug have been reported for Linux, Windows 98, Windows 2000, Windows XP and Windows Me - hence OS-type will be set to "All", as all means "more than one - and probably all".
OS: Linux → All
*** Bug 181094 has been marked as a duplicate of this bug. ***
*** Bug 179821 has been marked as a duplicate of this bug. ***
*** Bug 178395 has been marked as a duplicate of this bug. ***
*** Bug 178322 has been marked as a duplicate of this bug. ***
Attached patch my guess at a fix (obsolete) — — Splinter Review
nate@verse.com that's great. Can you do a few things for me? 1. verify my guess: in gdb use |up| to get to the nsTreeSelection frame (#1) and |p mTree| it really should say that mTree is null. Also check that aIndex>mMax (|p mMax| -- i'm betting mMax is -1). 2. still in gdb, use |up| a few more times to get to frame #3 / #4 and then |call DumpJSStack()|. That should give you another stack, but this time for the offendinug JS. For now it'd be enough if you could attach that to this bug, but if you like, you could use Venkman to set a breakpoint near the last JS frame and figure out if there's a bad assumption in that code. 3. test this patch (the problem is that mTree is null, but this code doesn't null check mTree so i think the correct fix is something closer to what i wrote). thanks.
Attached patch a version that compiles — — Splinter Review
... ok, so that other struct embedded in the file confused me. ignore hunt for max, it just isn't there...
Attachment #109397 - Attachment is obsolete: true
.
Assignee: hewitt → timeless
Component: Autocomplete → XP Toolkit/Widgets: Trees
Product: Phoenix → Browser
Version: unspecified → Trunk
Attachment #109411 - Flags: superreview?(hewitt)
Attachment #109411 - Flags: review?(varga)
Here's the additional gdb info that you requested. Because of the frozen window manager, I ended up retyping this attachment. Thus it's quite possible it contains a typo or two. It looks like mTree is non-null, but that _vptr. within it is NULL. I think this means your patch won't catch this case, but I'm uncertain how the XP wrappers work, and how one is supposed to peek inside them with gdb.
*** Bug 175302 has been marked as a duplicate of this bug. ***
timeless: maybe you should return NS_ERROR_INVALID_POINTER or _NOT_INITIALIZED here... (if that is applicable here, I didn't look at the file, only at your patch)
Does anyone have ideas on what might cause the situation in comment #13? Where is _vptr supposed to be set? Is there anything that might be overwriting it? This bug still grabs me multiple times per day. I should note that unlike the test case, it is often enough merely to mouse over the popup list without any clicking. I'm still eager to try to fix this problem, but I'm at a dead end. Timeless made a valiant effort, but I don't think his patch is going to be the right solution. Even if modified to check _vptr instead of mtree, it still doesn't solve the issue of why it is null in the first place. This bug seems related to multiple windows that contain (or have contained) the same form. What issues relate to multiple windows? Could this be a threading problem?
*** Bug 189139 has been marked as a duplicate of this bug. ***
*** Bug 189279 has been marked as a duplicate of this bug. ***
*** Bug 190270 has been marked as a duplicate of this bug. ***
*** Bug 191819 has been marked as a duplicate of this bug. ***
Comment on attachment 109411 [details] [diff] [review] a version that compiles this looks like a dangling pointer, not like a missing null check
Attachment #109411 - Flags: superreview?(hewitt)
Attachment #109411 - Flags: superreview-
Attachment #109411 - Flags: review?(varga)
Attachment #109411 - Flags: review-
If this is the same crash that I'm seeing, then it's caused by the tree selection's dangling pointer to the tree box object. Unfortunately that pointer doesn't get updated when the tree box object goes away or is recreated.
*** Bug 195387 has been marked as a duplicate of this bug. ***
*** Bug 195657 has been marked as a duplicate of this bug. ***
same here :(
Another thing: although I switched of the "save information ..." (not checked), phoenix still saves those entries and tries to auto complet unlee I clear it every few minutes ...
I thought I had stopped seeing this crash in newer builds, but then I hit it in the 3/12 bulid on Windows XP.
*** Bug 199398 has been marked as a duplicate of this bug. ***
Attached image Error message I received —
I'm running Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) Gecko/20030401 Phoenix/0.5 Phoenix used to just crash when I was using stable (Naples) 0.5. Then I downloaded the April 1st nightly build I got this error message. I was doing this when it crashed: Clicked on bookmark that took me to http://omahaultimate.tripod.com/ Then clicked on "Tell me when this page is updated" link that took me here: http://omahaultimate.tripod.com/bin/email_when_updated/display_form Then when I was typing in my email addy, the auto complete popped up and then I got the error message and Phoenix crashed.
*** Bug 200721 has been marked as a duplicate of this bug. ***
This has got to be fixed.
Flags: blocking1.4b?
Keywords: nsbeta1
Varga, can you help? /be
It looks like the problem a weak pointer that's not explicitly cleared when the object it points to goes away. This looks like the kind of thing that will work most of the time, unless something else happens to be holding on to the object that holds the weak pointer in addition to its normal ownership chain. (Could it be a strong pointer?)
Attached file valgrind output for the crash —
Here's some output from "valgrind" that might offer more clues at to what is happening here. (http://developer.kde.org/~sewardj/). Walking through it: WARNING: NS_ENSURE_TRUE(row != nsnull) failed, file nsFormHistory.cpp, line 283 This line is junk not related to the bug. The code is written badly, and it always causes this warning to appear. Perhaps this could be changed? WARNING: NS_ENSURE_TRUE(presShell) failed, file nsGenericHTMLElement.cpp, line 2684 Don't know what is causing this. Useful clue? ###!!! ASSERTION: Did you know you were calling |do_GetInterface()| on an object that doesn't support the |nsIInterfaceRequestor| interface?: 'factoryPtr', file nsIInterfaceRequestorUtils.cpp, line 50 New warning as a result of some recent changes for an unrelated bug. Assertion is raised when window is popup window containing form is closed. Might be showing a earlier symptom of same problem that causes the crash? Look at nsGlobalWindow.cpp:308 to see what causes this assertion. ==1667== Invalid memory access of size 4 ==1667== at 0x42B6C534: nsTreeSelection::SetCurrentIndex(int) (nsTreeSelection.cpp:595) This is valgrind catching the error that will cause the crash. mTree is all messed up by this point, so out attempts to work with it fail badly. ==1667== Address 0x45CD2CB8 is 0 bytes inside a block of size 36 free'd ==1667== at 0x40147FD4: free (vg_clientfuncs.c:185) ==1667== by 0x805A405: __builtin_delete (nsAppRunner.cpp:187) ==1667== by 0x40148079: operator delete(void*) (vg_clientfuncs.c:208) ==1667== by 0x428992CF: nsRange::~nsRange() (nsRange.cpp:447) This is interesting. On this run (but not on most of the runs I tried) valgrind is saying that the value of mTree (I think it is mTree) was previously freed by the destruction of nsRange. Which makes me think that if one knew when and why this was being called, one could probably solve this bug. On the other hand, most of the valgrind runs I've tried just say that the address is not stack'ed, alloc'ed, or free'd. So maybe this is just by chance? But it seems worth pursuing to me, particularly by some more knowledgeable than me.
Additional test case: Go to Google Enter text (don't submit) Hit Alt-D Enter text *Kaboom*
Scott, you are describing bug 194581.
if this is phoenix only, then not a blocker or 1.4 if you can reproduce this in a trunk Mozilla Seamonkey build.
Flags: blocking1.4b? → blocking1.4b-
Has this been fixed as a side-effect of recent changes to Phoenix/Firebird? I have been extensively using the nightly builds and have not had a crash with the 2003-04-15 and later builds. Can anyone still reproduce this with recent nightly builds?
> Has this been fixed as a side-effect of recent changes to Phoenix/Firebird? The bug is not fixed but there is a null check which traps the crash. See bug 201850 for more info.
I'm still experiencing the bug, so no, its not fixed. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030427 Mozilla Firebird/0.6
> I'm still experiencing the bug Likewise here (Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) Gecko/20030424 Mozilla Firebird/0.6). Process dump available on request.
per comment 22 and comment 33 this is not caused by a null pointer. therefore, that bug is unrelated to this one.
>(Could it be a strong pointer?) I don't think so, that would create a circular ref (box object -> view -> selection -> box object) We should change mTree to an nsWeakRef (or redesign the ownership model as a long term solution)
I have to admit I'm not sure I'm doing the right thing here but Firebird just crashed and I have an incident ID from Talkback: TB19775032W Is this the right place to submit such information?
Check out http://forums.hardwarezone.com/search.php?s= The search input box seems to demand focus even with this workaround. This is the main reason why I'm still seeing crashes I think. On most other sites focus is not given to the form history, but with this site, if you try to use autocomplete, you can see the focus shifted from entry to entry as you mouseover the autocomplete drop down menu, and this will inevitably cause crashes.
*** Bug 205304 has been marked as a duplicate of this bug. ***
*** Bug 205923 has been marked as a duplicate of this bug. ***
Still hasn't been fixed: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 This crashes the browser for me ALL THE TIME >:(
nate, can you try using valgrind with: --error-limit=no --num-callers=20 -v that should give useful info about the nsRange...
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
sugesting the change of the sumary to "Mozilla Firebird frequently crashes when form autocomplete is used"
Summary: Phoenix frequently crashes when form autocomplete is used → Mozilla Firebird (Phoenix) frequently crashes when form autocomplete is used
Attached file more valgrind —
Invalid read of size 4 nsTreeSelection::SetCurrentIndex(int) Address 0x4BFA45BC is 0 bytes inside a block of size 36 free'd free (vg_clientfuncs.c:185) __builtin_delete (nsAppRunner.cpp:187) operator delete(void*) (vg_clientfuncs.c:208) nsTreeBoxObject::~nsTreeBoxObject() (nsTreeBoxObject.cpp:105) and later... Invalid read of size 4 nsXULElement::QueryInterface(nsID const&, void**) (nsXULElement.cpp:669) Address 0x48FADA18 is 0 bytes inside a block of size 52 free'd free (vg_clientfuncs.c:185) __builtin_delete (nsAppRunner.cpp:187) operator delete(void*) (vg_clientfuncs.c:208) nsXULElement::~nsXULElement() (nsXULElement.cpp:495) longer stacks included in attachment
here's another talkback Incident ID: TB20406433G, this time my email address was supposed to autocomplete
Hi! Can anyone here still reproduce this bug using a clean profile with current nightly builds? I cannot reproduce this now.
I've not been able to reproduce this bug since I began using a build I created on May 26th. So far the build I created on May 28th hasn't crashed either. I've been using autocomplete pretty extensively, and its not crashed yet. When I used 0.6, it used to crash somewhat frequently. I've not been using official nightlies, but I've been building directly from CVS without adding any patches.
unable to reproduce with official nightly (may 23) but even though I have been able to trigger the test-case, that has been my only encounter with the autocomplete-bug.
Still happen for me: TB20543075M with 20030526 on WinXP.
It also happens to me all the time with build 20030526 on win2k and winxp. Also maybe pure coincidence, I have never had it crash in Linux and in windows I cannot intentionally make it crash. I realize that this really isn't appropriate to place here but this is a major bug that we've all been waiting months and months to be fixed. I don't know of any other bug that deserves more attention than this guys. I cannot recommend firebird to general users solely because of this bug. It is incredibly frustrating that this bug is being ignored (or so it appears). I've sent in probably 30 talkback reports with these crashes, is there anything else that can be done to help short of doing the actuall programming?
Bug persists in FB 2003052708 on Win2K: Crashes on Bidpay at the login prompt when recalling userid.
A workaround seems to be about:config | browser.formfill.enable | false. If you're not seeing this bug, maybe you've got that preference set. This bug applies to *form* autocomplete, not URL bar autocomplete.
Still crashing on 2003052708 WinXP. Does Mozilla suite have this bug? If not, what's the difference? I'd like to kill auto-complete in preference, though i'm not using release version, but testing... If we see no improvement in another month, then replacing entire auto-complete component in Firebird will be better. It won't take 1 month.
"A workaround seems to be about:config | browser.formfill.enable | false. If you're not seeing this bug, maybe you've got that preference set." Unfortunatelly that doesn't work, formfill is still used, that preference is ignored and crashes occur as well as formfilling anyway.
>Does Mozilla suite have this bug? If not, what's the difference? It doesn't. Form autocomplete was re-written in phoenix.
*** Bug 207504 has been marked as a duplicate of this bug. ***
I haven't been able to reproduce this bug since 20030521, however I know people who still can. Very weird.
Just reproduced with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030529 Mozilla Firebird/0.6
*** Bug 207975 has been marked as a duplicate of this bug. ***
In my experience you can ignore the autocomplete function or use the mouse. This makes the browser act fine/normal. This makes the autocomplete almost unusable, though. Using the mouse to click the autocomplete defeats the purpose of the feature, imo. I like this feature because it is supposed to save me time in filling out web forms. Having to switch from kb to mouse is not a savings by any stretch. This is nearly the sole reason that I have been resistant to Mozilla up until this point. Other than this glitch, Firebird beats IE6 hands down, and IE6 imo is it's only real competition. Please fix this bug so that I can start evangelizing in earnest.
>In my experience you can ignore the autocomplete function or use the mouse. This >makes the browser act fine/normal. My Mozilla Firebird still manages to crash if i use the mouse to select one of the auto-complete options so this does not make the browser "act" normal.
It appears that if you copy autocomplete.xpt from mozilla and use it in firebird that its a valid work around. I haven't yet experianced a crash and it of course doesn't have any side effects that i've seen. So those of you watching this thread... try autocomplete.xpt from mozilla (in components dir). I copied it from mozilla-win32-1.3.1-talkback.
making this summary a bit more queryable and adding stacktrace (this is the #1 crasher in 0.6 talkback) Stack Trace: nsTreeSelection::SetCurrentIndex [d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp line 597] nsTreeSelection::Select [d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp line 356] XPTC_InvokeByIndex [d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp line 102] XPCWrappedNative::CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 2025] XPC_WN_CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1285] js_Invoke [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 845] js_Interpret [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 2854] js_Invoke [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 861] js_InternalInvoke [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 936] js_InternalGetOrSet [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 979] js_SetProperty [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsobj.c line 2639] js_Interpret [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 2694] js_Invoke [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 861] nsXPCWrappedJSClass::CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp line 1334] nsXPCWrappedJS::CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp line 429] PrepareAndDispatch [d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp line 119] SharedStub [d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp line 147] nsAutoCompleteController::HandleKeyNavigation [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp line 292] nsFormFillController::KeyPress [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/satchel/src/nsFormFillController.cpp line 547] nsEventListenerManager::HandleEvent [d:/nightlybuild/phoenix/trunk/mozilla/content/events/src/nsEventListenerManager.cpp line 1637] nsGenericElement::HandleDOMEvent [d:/nightlybuild/phoenix/trunk/mozilla/content/base/src/nsGenericElement.cpp line 1925] nsHTMLInputElement::HandleDOMEvent [d:/nightlybuild/phoenix/trunk/mozilla/content/html/content/src/nsHTMLInputElement.cpp line 1445] PresShell::HandleEventInternal [d:/nightlybuild/phoenix/trunk/mozilla/layout/html/base/src/nsPresShell.cpp line 6397] PresShell::HandleEvent [d:/nightlybuild/phoenix/trunk/mozilla/layout/html/base/src/nsPresShell.cpp line 6320] nsViewManager::HandleEvent [d:/nightlybuild/phoenix/trunk/mozilla/view/src/nsViewManager.cpp line 2268] nsView::HandleEvent [d:/nightlybuild/phoenix/trunk/mozilla/view/src/nsView.cpp line 308] nsViewManager::DispatchEvent [d:/nightlybuild/phoenix/trunk/mozilla/view/src/nsViewManager.cpp line 2050] HandleEvent [d:/nightlybuild/phoenix/trunk/mozilla/view/src/nsView.cpp line 82] nsWindow::DispatchEvent [d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsWindow.cpp line 1058] nsWindow::DispatchWindowEvent [d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsWindow.cpp line 1075] nsWindow::DispatchKeyEvent [d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsWindow.cpp line 2932] nsWindow::OnKeyDown [d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsWindow.cpp line 3021] USER32.dll + 0x5793 (0x77d45793) Source File: d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp line : 597
Summary: Mozilla Firebird (Phoenix) frequently crashes when form autocomplete is used → firebird autocomplete crash nsTreeSelection::SetCurrentIndex select form field
Re comment #70: Gave this workaround a try but replacing Moz.Firebird 2003-06-03 autocomplete.xpt by the 2003-06-03 autocomplete.xpt from SeaMonkey causes Moz.Firebird to crash in XPCOM.DLL just right after selecting a profile. So at least on my box (WinNT4.0) this workaround seems to fail :(
.
Assignee: timeless → hewitt
Summary: firebird autocomplete crash nsTreeSelection::SetCurrentIndex select form field → firebird autocomplete crash [@ nsTreeSelection::SetCurrentIndex] select form field
um, just downloaded and installed the latest nightly build...IT'S WORKING!!! I tried all the same stuff that usually makes my junk crash, and it's working, just like IE does. arrow down to the result you want, press enter to select it, and enter to submit the form. I'm so happy I could cry. Mellissa
*** Bug 209257 has been marked as a duplicate of this bug. ***
I can still reproduce crashes - talkback IDs TB21031309M and TB21021441X. Also just reproduced with test case: TB21031609X. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030611 Mozilla Firebird/0.6 Re: comment 68: you cannot ignore the form autocomplete - it triggers automatically when typing into the text field - you cannot avoid it popping up, which is when it crashes. Re: comment 74: have you tried the test case again? Have you opened and closed windows?
Francis, I did try the test case. I followed the instructions correctly, and that all works fine, the only part that does not is after all that I typed fo into the form, and the foo1 and foo2 dropped down as choices. If I use the mouse to try to click on them, firebird crashes. But still, this is more than half the battle!!! For me this is great, because I rarely, if ever, use the mouse to click on these. Mellissa
I still get the crashes also... The bug is not fixed
Adding topcrash keyword since this is the #1 crash for Mozilla FireBird .06. Also see bug 189005. That might be a dup.
Keywords: topcrash
Summary: firebird autocomplete crash [@ nsTreeSelection::SetCurrentIndex] select form field → firebird autocomplete crash - MFB06 [@ nsTreeSelection::SetCurrentIndex] select form field
Adding nsTreeRange::Invalidate to summary since that stack signature is also being reported by Mozilla Firebird .06 users trying to use autocomplete. Here is the latest from Talkback for those crashes: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Rank StackSignature Count 11 nsTreeRange::Invalidate 66 Source File : d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp line : 216 ==================================================================================================== Count Offset Real Signature [ 5 nsTreeRange::Invalidate a2172430 - nsTreeRange::Invalidate ] [ 3 nsTreeRange::Invalidate 823caccd - nsTreeRange::Invalidate ] [ 3 nsTreeRange::Invalidate 13e4a738 - nsTreeRange::Invalidate ] [ 2 nsTreeRange::Invalidate 8af81454 - nsTreeRange::Invalidate ] [ 2 nsTreeRange::Invalidate 5e95cd7d - nsTreeRange::Invalidate ] Crash date range: 2003-06-06 to 2003-06-13 Min/Max Seconds since last crash: 2904 - 1396050 Min/Max Runtime: 19834 - 2227763 Count Platform List 8 Windows NT 5.1 build 2600 5 Windows NT 5.0 build 2195 2 Windows NT 4.0 build 1381 Count Build Id List 15 2003051616 No of Unique Users 15 Stack trace(Frame) nsTreeRange::Invalidate [d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp line 216] nsTreeSelection::Select [d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp line 371] XPTC_InvokeByIndex [d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp line 102] XPCWrappedNative::CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 2025] XPC_WN_CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1285] js_Invoke [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 845] js_Interpret [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 2854] js_Invoke [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 861] js_InternalInvoke [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 936] js_InternalGetOrSet [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 979] js_SetProperty [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsobj.c line 2639] JS_SetProperty [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsapi.c line 2456] nsXPCWrappedJSClass::CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp line 1314] nsXPCWrappedJS::CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp line 429] PrepareAndDispatch [d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp line 119] SharedStub [d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp line 147] nsAutoCompleteController::ClosePopup [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp line 653] nsAutoCompleteController::ProcessResult [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp line 868] nsAutoCompleteController::OnSearchResult [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp line 382] nsFormFillController::StartSearch [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/satchel/src/nsFormFillController.cpp line 429] nsAutoCompleteController::StartSearch [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp line 688] nsAutoCompleteController::Notify [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp line 395] nsTimerImpl::Fire [d:/nightlybuild/phoenix/trunk/mozilla/xpcom/threads/nsTimerImpl.cpp line 395] nsAppShell::Run [d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsAppShell.cpp line 143] nsAppShellService::Run [d:/nightlybuild/phoenix/trunk/mozilla/xpfe/appshell/src/nsAppShellService.cpp line 479] main1 [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/xre/nsAppRunner.cpp line 1297] xre_main [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/xre/nsAppRunner.cpp line 1698] main [d:/nightlybuild/phoenix/trunk/mozilla/browser/app/nsBrowserApp.cpp line 52] WinMain [d:/nightlybuild/phoenix/trunk/mozilla/browser/app/nsBrowserApp.cpp line 65] WinMainCRTStartup() kernel32.dll + 0x214c7 (0x77e814c7) (21016980) URL: www.imdb.com (21016980) Comments: Filling in search form (21006586) Comments: typing in text box drop-down list of history appears then crashes (20996103) Comments: autocomplete (20974781) Comments: filling out php form (20950011) URL: usercenter.checkpoint.com (20950011) Comments: Authenticating to an ssl site (20824904) URL: http://www.gutrumbles.com (20824904) Comments: once again I was posting on a weblog and duh!! (20821611) URL: maps.yahoo.com (20821611) Comments: autocomplete (again) (20819446) URL: http://www.google.co.uk/imghp (20819446) Comments: Started typing in to the search box and it crashed (20816092) Comments: opened new tab... i had windows update service pack 1 in backround that just switched from unzipping to downloading patches and updates ==================================================================================================== Count Offset Real Signature [ 5 nsTreeRange::Invalidate 644566b0 - nsTreeRange::Invalidate ] [ 3 nsTreeRange::Invalidate d5b6e5b8 - nsTreeRange::Invalidate ] [ 2 nsTreeRange::Invalidate 446eee4d - nsTreeRange::Invalidate ] Crash date range: 2003-06-06 to 2003-06-14 Min/Max Seconds since last crash: 63 - 1544878 Min/Max Runtime: 28790 - 1544878 Count Platform List 7 Windows NT 5.1 build 2600 3 Windows NT 5.0 build 2195 Count Build Id List 10 2003051616 No of Unique Users 10 Stack trace(Frame) nsTreeRange::Invalidate [d:/nightlybuild/phoenix/trunk/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp line 216] 0xffffffff XPCWrappedNative::CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 2025] XPC_WN_CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1285] js_Invoke [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 845] js_Interpret [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 2854] js_Invoke [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 861] js_InternalInvoke [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 936] js_InternalGetOrSet [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsinterp.c line 979] js_SetProperty [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsobj.c line 2639] JS_SetProperty [d:/nightlybuild/phoenix/trunk/mozilla/js/src/jsapi.c line 2456] nsXPCWrappedJSClass::CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp line 1314] nsXPCWrappedJS::CallMethod [d:/nightlybuild/phoenix/trunk/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp line 429] PrepareAndDispatch [d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp line 119] SharedStub [d:/nightlybuild/phoenix/trunk/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp line 147] nsAutoCompleteController::ClosePopup [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp line 653] nsAutoCompleteController::ProcessResult [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp line 868] nsAutoCompleteController::OnSearchResult [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp line 382] nsFormFillController::StartSearch [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/satchel/src/nsFormFillController.cpp line 429] nsAutoCompleteController::StartSearch [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp line 688] nsAutoCompleteController::Notify [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp line 395] nsTimerImpl::Fire [d:/nightlybuild/phoenix/trunk/mozilla/xpcom/threads/nsTimerImpl.cpp line 395] nsAppShell::Run [d:/nightlybuild/phoenix/trunk/mozilla/widget/src/windows/nsAppShell.cpp line 143] nsAppShellService::Run [d:/nightlybuild/phoenix/trunk/mozilla/xpfe/appshell/src/nsAppShellService.cpp line 479] main1 [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/xre/nsAppRunner.cpp line 1297] xre_main [d:/nightlybuild/phoenix/trunk/mozilla/toolkit/xre/nsAppRunner.cpp line 1698] main [d:/nightlybuild/phoenix/trunk/mozilla/browser/app/nsBrowserApp.cpp line 52] WinMain [d:/nightlybuild/phoenix/trunk/mozilla/browser/app/nsBrowserApp.cpp line 65] WinMainCRTStartup() kernel32.dll + 0x214c7 (0x77e814c7) (21042799) URL: http://www.google.com (21040563) URL: www.amazon.com (21040563) Comments: I had three windows open I was on Autotrader.com and entering my zip when it froze then crashed. (21030930) Comments: Filling in a form. First time ever I got the dreaded form autocomplete. :-( I would actually like to turn it OFF but there's that other bug... (20910964) URL: www.google.com (20910964) Comments: Googled. Did a Back entered new search criteria pressed Enter boom crash...
Summary: firebird autocomplete crash - MFB06 [@ nsTreeSelection::SetCurrentIndex] select form field → Firebird autocomplete crash - MFB06 [@ nsTreeSelection::SetCurrentIndex] [@ nsTreeRange::Invalidate] select form field
*** Bug 209950 has been marked as a duplicate of this bug. ***
Came to bugzilla to report an autocomplete crash in Phoenix 0.5 and Firebird 0.6 (exists in both), and I'm almost certain it's a dupe of this. Joy. So instead, I'll vote for this bug and contribute another surefire test case. This repros on Firebird/0.6 on MacOS X and Win32. (oooh, cross platform!) go to http://www.haagen-dazs.com click "Promotions and Events" Pick one of the two contests on the left, enter your personal information and submit the entry. Agree to save form data. Pick the other contest, fill out the data. It's sort of unpredictable - sometimes, you have to double-click the autocomplete data in the dropdown list to break Firebird, and other times it breaks when just typing the data in without clicking anything. Either way, if it doesn't blow up in the second attempted contest entry, close that popup window and open up a third and it will. This isn't anything new... reading through past comments, it sounds like some work had been done tracing it to popup windows, and that is definitely the case here (they placed the entry blank as a popup). I expect the test case already in the bug is the same exact problem. I filed a talkback incident, id TB21258314E, from a Win2k box just in case that helps.
Alias: autocomplete
Neil has a possible fix for this. I can't reproduce this bug on linux, but from my point of view Neil's patch looks promising.
Attached patch Patch based on bug 190447 — — Splinter Review
This will stop pointers from dangling. Any remaining crash would then be caused by a null pointer.
Attachment #126461 - Flags: review+
can't wait for a (new) beos-nightly, since I also ran into this: (enclosing my stack-crawl in case it's useful) loading symbols segment violation occurred 00650068 read_fault MozillaFirebird-bin:sc frame retaddr fcfffecc ed27d5d1 nsTreeSelection::Select(int) + 00000035 fcfffee8 ec9e7f5f XPTC_InvokeByIndex + 00000057 fcffff0c ecba1b5d XPCWrappedNative::CallMethod(XPCCallContext &, XPCWrappedNative::CallMode) + 00000c95 fd000118 ecba6f42 XPC_WN_CallMethod(JSContext *, JSObject *, unsigned int, long *, long *) + 000000a2 fd0001c4 ec90a143 js_Invoke + 0000058f fd000290 ec9115c2 js_Interpret + 00006916 fd000458 ec90a193 js_Invoke + 000005df fd000518 ec90a397 js_InternalInvoke + 000000a7 fd0005a4 ec90a4be js_InternalGetOrSet + 000000e6 fd0005d4 ec91bb36 js_SetProperty + 0000028a fd000650 ec910b77 js_Interpret + 00005ecb fd00081c ec90a193 js_Invoke + 000005df fd0008dc ecb9df73 nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS *, unsigned short, nsXPTMethodInfo const *, nsXPTCMiniVariant *) + 00000c03 fd000b00 ecb99dd2 nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const *, nsXPTCMiniVariant *) + 0000003e fd000b28 ec9e80ef PrepareAndDispatch(nsXPTCStubBase *, unsigned long, unsigned int *) + 0000017f fd000be8 ec9e82bc nsXPTCStubBase::Stub11(void) + 00000024 fd000c00 eddf3d14 nsAutoCompleteController::HandleKeyNavigation(unsigned short, int *) + 00000130 fd000ccc ede04a1a nsFormFillController::KeyPress(nsIDOMEvent *) + 000001ea fd000d08 ed11ec74 nsEventListenerManager::HandleEvent(nsIPresContext *, nsEvent *, nsIDOMEvent **, nsIDOMEventTarget *, unsigned int, nsEventStatus *) + 00001618 fd000e98 ed0c7262 nsGenericElement::HandleDOMEvent(nsIPresContext *, nsEvent *, nsIDOMEvent **, unsigned int, nsEventStatus *) + 000008b2 fd000fe0 ed163403 nsHTMLInputElement::HandleDOMEvent(nsIPresContext *, nsEvent *, nsIDOMEvent **, unsigned int, nsEventStatus *) + 0000079f fd001240 ecfa54f2 PresShell::HandleEventInternal(nsEvent *, nsIView *, unsigned int, nsEventStatus *) + 000002b6 fd0012a8 ecfa516f PresShell::HandleEvent(nsIView *, nsGUIEvent *, nsEventStatus *, int, int &) + 000005a7 fd001320 ed2662f0 nsViewManager::HandleEvent(nsView *, nsGUIEvent *, int) + 000000dc fd001400 ed25e5ba nsView::HandleEvent(nsViewManager *, nsGUIEvent *, int) + 00000026 fd001420 ed265ac3 nsViewManager::DispatchEvent(nsGUIEvent *, nsEventStatus *) + 00000827 fd00149c ed25e034 HandleEvent(nsGUIEvent *) + 00000044 fd0014bc ed75746d nsWindow::DispatchEvent(nsGUIEvent *, nsEventStatus &) + 00000049 fd0014d8 ed7574e2 nsWindow::DispatchWindowEvent(nsGUIEvent *) + 00000036 fd0014f8 ed75af58 nsWindow::DispatchKeyEvent(unsigned int, unsigned int, unsigned int) + 000000bc fd001578 ed75adfd nsWindow::OnKeyDown(unsigned int, char const *, long, unsigned int, unsigned int, long) + 00000205 fd0015a0 ed75a84f nsWindow::CallMethod(MethodInfo *) + 0000045f fd001640 ed752526 nsAppShell::Run(void) + 000000ba fd001668 ed717a88 nsAppShellService::Run(void) + 00000024 fd001678 8000ef62 main1(int, char **, nsISupports *, nsXREAppData const &) + 000008be fd001784 8000f541 xre_main(int, char **, nsXREAppData const &) + 000002a5 fd0017e4 8000b4f6 main + 00000092 fd001824 8000b355 _start + 00000061 MozillaFirebird-bin:regs eax 00650068 ebp fcfffecc cs 001b edx 0000002f esi 80fc6030 ss 0023 ecx 804575e0 edi 00000000 ds 0023 ebx ed58a0bc esp fcfffeb4 es 0023 fs 340b eflags 00010286 eip 00650068 trap_no 0000000e error_code 00000005 MozillaFirebird-bin:ps PID DEBUG NAME STATUS 672 curr MozillaFirebird-bin semaphore 675 BApplication semaphore 67a moz-thread semaphore 67b moz-thread semaphore 67e moz-thread semaphore d14 moz-thread semaphore ddc w>PegasosPPC.com - - Mozilla Fi semaphore de9 w> semaphore dea w> semaphore e33 w> semaphore e34 w> semaphore e35 team 243 debugtask semaphore MozillaFirebird-bin: brg, Hugh
Still present as of nightly build 06/26 on Windows XP Pro. Fresh install, fresh profile, first thing I tried. I can reproduce it 100% so if anyone needs to see it happen... It didn't appear to happen with the first time I tried it, so I tried it again, and sure enough, crash.
Comment on attachment 126461 [details] [diff] [review] Patch based on bug 190447 jag, could you sr?
Attachment #126461 - Flags: superreview?(jaggernaut)
Comment on attachment 126461 [details] [diff] [review] Patch based on bug 190447 Just to make sure, in the |!sel| case where you create a new TreeSelection, shouldn't you also do sel->SetTree()?
jag: NS_NewTreeSelection(mTreeBoxObject, getter_AddRefs(sel)); effectively calls sel->SetTree(mTreeBoxObject); in the nsTreeSelection constructor.
Comment on attachment 126461 [details] [diff] [review] Patch based on bug 190447 sr=jag
Attachment #126461 - Flags: superreview?(jaggernaut) → superreview+
Just checked the fix in, so let's see if this makes any difference.
I tried to test it with the 20030709 build, but it looks like auto-completion has been disabled ? ("browser.formfill.enable" is set to "true")
disabled or broken - bug 212220. Seems to have stopped working before this was checked in, so probably not related. But obviously it's not possible to test this until autocomplete actually works...
There are still some wired behaviors about autocomplete. But, so far I can see no autocomplete crash anymore!
noririty, what build are you using?
*** Bug 212588 has been marked as a duplicate of this bug. ***
*** Bug 212657 has been marked as a duplicate of this bug. ***
Using an unoffical 07/14 build, on Windows XP, I get the following behaviour: using the keyboard only, if there are >1 items on the autocomplete list you can only select the first item. As soon as you press the down arrow button, it automatically selects the first item and returns you to the field. Using the mouse you can select any of the items....ah....after some more testing, it appears to try and auto-limit the entries such that as you select entries it narrows the list. Still some oddities there, but at least no crashes!
I tried cvs HEAD. Marking as FIXED as I can still confirm fixed with 2003-07-14-15-trunk. Selecting with keyboard issue should be filed with another bug.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Finally its fixed, I'm one happy guy :) Anyway, the selecting with keyboard issue has been filed by myself yesterday as Bug 212686
*** Bug 212890 has been marked as a duplicate of this bug. ***
verified fixed.
Status: RESOLVED → VERIFIED
*** Bug 212952 has been marked as a duplicate of this bug. ***
*** Bug 212969 has been marked as a duplicate of this bug. ***
*** Bug 215337 has been marked as a duplicate of this bug. ***
*** Bug 215363 has been marked as a duplicate of this bug. ***
Found out that bug 216483 was a dupe of this bug. I already marked (my own) bug report as invalid. Yes, another case of this in Firebird 0.6.
*** Bug 190447 has been marked as a duplicate of this bug. ***
*** Bug 217704 has been marked as a duplicate of this bug. ***
*** Bug 223593 has been marked as a duplicate of this bug. ***
I am able to produce an apparently autocomplete related crash in Firefox 0.9.1 on Linux/amd64 (Gentoo ~amd64, last emerge -u world 2004/July/21). I was able to reproduce consistantly with the following steps: 1.) Start firefox. 2.) Go to http://www.google.com/ (It seems to be able to crash on any form a text control and remembered stuff to autocomplete) 3.) Type in something that will cause autocomplete to pop up with choices, my tests had 2 or three different choices, but one choice may crash too. 4.) It might crash. If it doesn't, delete the text in the box and type it again. Typing speed *may* be linked - it seems like it crashes more if I'm typing quickly, but that's probably just that it has more chances to crash. 5.) In order to reproduce, I need to repeat step 3 an average of 3 times. This comes up (frequently) in normal browsing, so it's not nessisary to repeat it on a given form element to work, but it may not trigger on the first form element filled during the browser session - on the other hand, it may. I'd have opened a new bug, but it looks like every bug that was even vaguely similar to this got DUPED to this bug.
Nat: Did a Talkback Quality Feedback Agent popup when you crashed? If you submitted an incident, please post the id here. You can find it by running talkback in the mozilla components/talkback directory. If you didn't see a crash dialog after the crash, install a recent release or nightly with Talkback and try crashing again. Thanks.
Jay: I can't find an easy way to get a talkback build running on my platform (mostly-pure 64bit amd64 Linux). I don't have a 32bit Linux system to try that on, but I may be able to fake it later. I cannot duplicate the crash on WinXP.
nat@ferrus.net: please file a new bug.
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: asa → xptoolkit.widgets
Alias: autocomplete
Crash Signature: [@ nsTreeSelection::SetCurrentIndex] [@ nsTreeRange::Invalidate]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: