I think this is NOT a dup of bug 82332, that bug is for the crash [@ nsAString::do_AssignFromReadable] not [@ nsAString::AssignFromReadable]. It looks like that bug has been fixed, but the latest Talkback reports are showing this similar crash with recent Trunk builds. Here's the info: nsAString::AssignFromReadable 26 First BBID :31672862 Last BBID :31895684 Min Runtime :6 Max Runtime :2624 First Appearance Date : 2001-06-13 Last Appearance Date : 2001-06-18 First BuildID : 2001061222 Last BuildID : 2001061809 Stack Trace: nsAString::AssignFromReadable [d:\builds\seamonkey\mozilla\string\src\nsAString.cpp line 198] nsAutoCompleteItem::GetValue [d:\builds\seamonkey\mozilla\xpfe\components\autocomplete\src\nsAutoComplete.cpp line 47] XPTC_InvokeByIndex [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp line 139] XPCWrappedNative::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp line 1883] XPC_WN_GetterSetter [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp line 1285] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 809] js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 897] js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c line 2409] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 2541] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 825] nsXPCWrappedJSClass::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp line 991] nsXPCWrappedJS::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp line 427] PrepareAndDispatch [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp line 102] SharedStub [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp line 124] nsOutlinerBodyFrame::PaintText [d:\builds\seamonkey\mozilla\layout\xul\base\src\outliner\src\nsOutlinerBodyFrame.cpp line 1965] nsOutlinerBodyFrame::PaintCell [d:\builds\seamonkey\mozilla\layout\xul\base\src\outliner\src\nsOutlinerBodyFrame.cpp line 1789] nsOutlinerBodyFrame::PaintRow [d:\builds\seamonkey\mozilla\layout\xul\base\src\outliner\src\nsOutlinerBodyFrame.cpp line 1623] nsOutlinerBodyFrame::Paint [d:\builds\seamonkey\mozilla\layout\xul\base\src\outliner\src\nsOutlinerBodyFrame.cpp line 1530] PresShell::Paint [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5249] nsView::Paint [d:\builds\seamonkey\mozilla\view\src\nsView.cpp line 275] nsViewManager::RenderDisplayListElement [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp line 1438] nsViewManager::RenderViews [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp line 1363] nsViewManager::Refresh [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp line 900] nsViewManager::DispatchEvent [d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp line 1957] HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp line 68] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 719] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 741] nsWindow::OnPaint [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 4032] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 3027] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 984] USER32.DLL + 0x2e98 (0x77de2e98) USER32.DLL + 0x39a3 (0x77de39a3) USER32.DLL + 0x395f (0x77de395f) ntdll.dll + 0x2032f (0x77fa032f) USER32.DLL + 0x5824 (0x77de5824) nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp line 418] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1146] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1440] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1458] WinMainCRTStartup() KERNEL32.dll + 0x17d08 (0x77e67d08) Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/string/src/nsAString.cpp line : 198 (31879818) Comments: When I type www. into the address bar (31879816) Comments: When I type www. into the address bar (31874256) URL: www.google.com (31874256) Comments: Typing in a new URL manually when Mozilla 2001061804 crashed with page fault in XPCOM.DLL (I think) (31827547) URL: http://forum.fuckedcompany.com/phpcomments/index.php?newsid=12825401589&page=1&parentid=0&crapfilter=1 (31827547) Comments: autocompletion. Didn't get past "ww..." before it crashed. (31816353) URL: http://forum.fuckedcompany.com/phpcomments/index.php?newsid=12825401589&page=1&parentid=0&crapfilter=1 (31816353) Comments: Running browser buster (31775897) Comments: Forgot that I can't wrote in the browser field... damn. (31774635) Comments: Started to write in the browser field. Works most of the time though. (31748453) Comments: seemingly if I delete part of any URL by highlighting and pressing the delete key Moz crashes (31748420) Comments: was reading a bugzilla bug (31744825) URL: http://forum.fuckedcompany.com/phpcomments/index.php?newsid=12825401589&page=1&parentid=0&crapfilter=1 (31744825) Comments: location bar autocompletion. "www.s" crashed the app (31736104) Comments: After typing over a selected text in url bar or emptied url bar crash. (31735994) URL: www.tweakers.net (31735994) Comments: trying to type in about:while page was stil lloading (31730102) Comments: Tried to write something in the location field for the third time (31729882) Comments: Started to write in the location field. Only managed to write one w this time. (31729851) Comments: Opened it and started to type in the location field. Only managed to write ww before Mozilla crashed. (31713921) Comments: OK (31713921) Comments: I start to type a URL in (31713805) Comments: I was starting to type "http://www.mozilla.org" in the browser URL box. (31675245) URL: java.sun.com (31675245) Comments: Anything typed into "Open Web Location" dialog causes a crash (31673730) URL: java.sun.com (31673730) Comments: Typed CTRL-SH-L. Started typing www.t (31673627) URL: java.sun.com (31673627) Comments: Hit CTRL-O. Escaped (ESC). Hit CTRL-SH-L. Started typing and it crashed. (31672862) URL: http://forum.fuckedcompany.com/phpcomments/index.php?newsid=12825401589&page=1&parentid=0&crapfilter=1 (31672862) Comments: just typing in the start of a URL into the location bar
Not XML, trying autocomplete...
Assignee: heikki → hewitt
Component: XML → XP Apps: Autocomplete
QA Contact: petersen → blake
http://climate.mcom.com/reports/incidenttemplate.cfm?bbid=31775897 shows that the instruction on which the crash happened is 60ed3888 ff5024 call dword ptr [eax+0x24] and the register EAX contains 00000000. AssignFromReadable was not virtual whereas do_AssignFromReadable is virtual. So it looks to me like nsAutoCompleteItem::GetValue is being passed a reference to null.
Joe,et al- is this on the radar to resolve in time for the next release?
I have no idea what to do here. If the nsAWritableString is null, as a reference I can't really check it as such. This is code AlecF wrote, though this is probably not his bug either. He'll probably more less clueless than me, though, so I'll give it to him for now.
Assignee: hewitt → alecf
I think this has got to be a bug with XPConnect! value is an attribute, but somehow js is passing in a null reference. makes no sense at all. reassigning to jband, but continuing to investigate
Assignee: alecf → jband
wait, the one other possibility is that AssignFromReadable isn't handling an empty string well. Continuing to investigate, but adding scc to the list
alecf, jband's on vacation and I'm the new over of xpconnect anyway. So depending on what you find out, reassign it to me.
no, dbaron is right.. so I think this is an xpconnect bug.. I just wish I could reproduce this so that I could look at the JS stack and see where we're accessing the .value attribute. The only place in JS that I see a potential call is: http://lxr.mozilla.org/seamonkey/source/xpfe/components/autocomplete/resources/content/autocomplete.xml#290 and this code looks reasonable. maybe the fact that we're returning the value, rather than assigning it to another variable?
Assignee: jband → dbradley
I'm still not reproducing this on Win2k, can we get some testing coverage on Win98? That's where dbaron's link points us, don't know about the other reports. I think this is a 0.9.2 topcrash, so I would suggest we get this into the netscape rtm
I'm unable to reproduce this on Win2k or Linux. I'm going to need some help reproducing it and finding the problem. Under Win2k I verified that this code is executing properly. It got to the nsAutoCompleteItem::GetValue function from the call of GetCellText with no problem. At best this might be a Win98/XPConnect issue, but I would think a lot of other things would be breaking on Win98 if this was the case. If someone can reproduce it on Win98 and set a break point in nsOutlinerBodyFrame::PaintText at the line below and check the values. I'm curious if mView or any of the parameters are null. mView->GetCellText(aRowIndex, aColumn->GetID(), getter_Copies(text)); In the mean time I'll see if I can figure out any holes in code.
Status: NEW → ASSIGNED
One other thing I noticed is that when I execute the code, it goes through nsAString::AssignFromReadable and not nsACString::AssignFromReadable. I don't know if that will spark an inspiriate with anyone, but I thought I'd throw it out. In the mean time I'll see if I can create the case where it goes through nsACString::AssignFromReadable. Again if someone can reproduce this, I'd be interested knowing the values of the parameters I stated above.
Blake, are you really the QA contact for this? We're going to need a Dev Win98 box at least to try an attempt to reproduce, otherwise I'm at an impasse.
My previous comment that this was a reference to NULL was incorrect. It would be a reference to a string that has a NULL vtable pointer, which is likely a deleted string. (The call instruction relies on the object pointer already having been dereferenced to load the vtable pointer, so that one can execute the code at a location obtained from dereferencing an offset from the vtable pointer.) There is another topcrash that seems to me like it is likely the same problem -- the crashes occurring at stack nsXULAttributeValue::SetValue. For the crash in this bug, it's a getter for an |attribute AString value| and for the nsXULAttributeValue::SetValue crash, it's a setter for an |attribute DOMString flex|. However, in both cases, it's clear from the disassembly and registers that the function is being passed a reference to an AString with a null vtable pointer.
I concur with dbaron's assessment that the line he indicates represents a null vtbl pointer of the passed in object. I traced this in the debugger to this point (on a call that worked right, unfortunately) and it does match up as suggested. I was *hoping* that he was mistaken and the callee object had a bogus string that it was trying to assign into the caller's string. But that is not the case. I'm at a loss here. I can't get this to fail with Win32 builds for DEBUG or non-DEBUG running on NT4 or WinMe. The code path through xpcwrappednative.cpp for this call looks right. We make an nsString using 'new nsString()' and pass it's address. There is no path I can see that should whack that object before this call returns. I'm stuck grasping at the straw of memory corruption. I'll fiddle using autocomplete under Purify and report back.
My fishing with Purify did not uncover any problems.
*** Bug 99528 has been marked as a duplicate of this bug. ***
Adding [@ nsXULAttributeValue::SetValue] to summary for tracking (bug 99528 has been marked a dup of this one).
Summary: Trunk crash [@ nsAString::AssignFromReadable] → Trunk crash [@ nsAString::AssignFromReadable][@ nsXULAttributeValue::SetValue]
I talked with dbradley about this bug and here's where I think we ended up... - No one has reproduced this - we only get talkback reports. - Many of the reports indicate that this is a startup crash. - The path through the code looks right. - We both tried and failed to find corruption using Purify. I'm fairly well convinced that we are likely seeing the effects of out of date type information (.xpt file information). I see that these talkback builds are distributed as zip files - and *not* as installer builds. This means that users would be manually unzipping them. This makes it *very* likely that some users will unzip them on top of old builds. And, without the installer running, there is no code that forces an autoregistration or removes stale files (esp. old dlls or xpt files). This is bad. Incorrect xpt info can have us calling the wrong method in an interface and/or incorrectly passing the parameters. That would surely cause this sort of crash.
Here are some recent comments from the MozillaTrunk topcrash report for crashes with the nsXULAttributeValue::SetValue stack signature: Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/xul/content/src/nsXULAttributeValue.cpp line : 94 (36057781) Comments: Trying to start it (36031202) URL: http://geekbabe.com/monica/ircchat.html (36031202) Comments: Loading Mozilla. (36028050) Comments: have been using 0.94. now (for the first time ever) replaced the contents of c:\Programme\mozilla with the contents of the nightlybuild's (09/28) bin directory I have downloaded. crashed wheni first started it. (35980213) URL: http://geekbabe.com/monica/ircchat.html (35980213) Comments: Loading Communicator. (35973967) URL: http://geekbabe.com/monica/ircchat.html (35973967) Comments: Loading Communicator. (35973949) URL: http://geekbabe.com/monica/ircchat.html (35973949) Comments: Loading Communictor. (35961655) Comments: Starting up Mozilla (35961589) Comments: Starting up Mozilla (35780667) Comments: start crash after update from 0.94 to 22092001 Version (35710398) Comments: Trying to open Mail crashed immediately
Summary: Trunk crash [@ nsAString::AssignFromReadable][@ nsXULAttributeValue::SetValue] → Trunk crash [@ nsXULAttributeValue::SetValue][@ nsAString::AssignFromReadable]
And those all appear to be startup issues and would seem to point to issue of stale xpt information. 36028050 even states they copied binaries to the bin directory.
ok, since this is still a topcrasher and we know why these users are crashing, what can we do about it? is there a release note anywhere or a website we can send users to so that they may avoid future crashes?
Summary: Trunk crash [@ nsXULAttributeValue::SetValue][@ nsAString::AssignFromReadable] → Trunk & M095 crash [@ nsXULAttributeValue::SetValue][@ nsAString::AssignFromReadable]
Removing [@ nsAString::AssignFromReadable] from summary, since the original crash reported is no longer related to the startup crash in [@ nsXULAttributeValue::SetValue], which is still happening with Mozilla 0.9.5...here are a couple incidents: nsXULAttributeValue::SetValue 4a06815a BBID: 36649784 Unpacked the 0.9.5 zip into the old directory and started mozilla. Build: 2001101120 Crash Date: 2001-10-13 1 sec. Using running on Windows NT 5.0 build 2195 src_file d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULAttributeValue.cpp line 94 nsXULAttributeValue::SetValue a6600e58 BBID: 36751937 Copied installation win32 talkback over 0.94 installation and received an error on starting mozilla 0.95 Build: 2001101120 Crash Date: 2001-10-15 3 sec. Using running on Windows NT 4.0 build 1381 src_file d:/builds/seamonkey/mozilla/content/xul/content/src/nsXULAttributeValue.cpp line 94
Summary: Trunk & M095 crash [@ nsXULAttributeValue::SetValue][@ nsAString::AssignFromReadable] → Trunk & M095 crash [@ nsXULAttributeValue::SetValue]
> Unpacked the 0.9.5 zip into the old directory and started mozilla. Don't do that, then. Mixing component versions is a recipe for disaster, and we don't have the time to spend tracking down crashes that are caused by mismatches.
Mike: You don't have to tell me that...or anyone cc'd on this bug, since we know not to do that...but what about those people that are doing it? I just wanted to know if we have a relnote or help page setup for people that might be seeing this crash...so we can tell them not to do it.
The very first thing in the "Installation Notes" section of our release notes for 0.9.5 is: > Install into a new empty directory. Installing on top of previously installed > builds may cause problems. Does the installer warn about this problem?
Mike: that is a good point. We need to include some check to make sure we are not installing over an older existing installation.
So do we want to turn this bug into the need for a check to see if we're installing into an existing install, and get it assigned to whoever is responsible for the installation code?
Marking this invalid, since the release notes state not to do this. I'm not sure how you'd programmatically prevent someone from unzipping files into an existing installation. Shorting of coming up with a versioning system. I think the installer has an alert for this situation, there are a couple bugs concerning wording and such, 76103 for example. So I assume there's nothing to do on that front. Reopen if there is something that can truly be done to prevent this.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Component: XP Apps: Autocomplete → Installer
Resolution: --- → INVALID
*** Bug 116322 has been marked as a duplicate of this bug. ***
Crash Signature: [@ nsXULAttributeValue::SetValue]
You need to log in before you can comment on or make changes to this bug.