Closed Bug 86783 Opened 23 years ago Closed 23 years ago

Trunk & M095 crash [@ nsXULAttributeValue::SetValue]

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: jay, Assigned: dbradley)

References

Details

(Keywords: crash, topcrash)

Crash Data

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
Keywords: crash, topcrash
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
Closed: 23 years ago
Component: XP Apps: Autocomplete → Installer
Resolution: --- → INVALID
*** Bug 116322 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Crash Signature: [@ nsXULAttributeValue::SetValue]
You need to log in before you can comment on or make changes to this bug.