Trunk & M095 crash [@ nsXULAttributeValue::SetValue]



17 years ago
14 years ago


(Reporter: jay, Assigned: David Bradley)


({crash, topcrash})

Windows NT
crash, topcrash

Firefox Tracking Flags

(Not tracked)


(crash signature)



17 years ago
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: 

[d:\builds\seamonkey\mozilla\string\src\nsAString.cpp  line 198]
 line 47]
line 139]
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp  line 1883]
line 1285]
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 809]
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 897]
[d:\builds\seamonkey\mozilla\js\src\jsobj.c  line 2409]
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 2541]
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 825]
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp  line 991]
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp  line 427]
line 102]
line 124]
 line 1965]
 line 1789]
 line 1623]
 line 1530]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 5249]
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp  line 275]
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp  line 1438]
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp  line 1363]
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp  line 900]
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp  line 1957]
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp  line 68]
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp  line 719]
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp  line 741]
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp  line 4032]
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp  line 3027]
[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)
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp  line 418]
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1146]
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1440]
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1458]
	 KERNEL32.dll + 0x17d08 (0x77e67d08)
 	Source File :
line : 198
     (31879818)	Comments: When I type www. into the address bar
     (31879816)	Comments: When I type www. into the address bar
     (31874256)	URL:
Comments: Typing in a new URL manually when Mozilla 2001061804 crashed with page
fault in XPCOM.DLL (I think)
     (31827547)	URL:
Comments: autocompletion.  Didn't get past "ww..." before it crashed.
     (31816353)	URL:
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:
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:
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 "" in the browser URL
     (31675245)	URL:
     (31675245)	Comments: Anything typed into "Open Web Location" dialog causes a crash
     (31673730)	URL:
     (31673730)	Comments: Typed CTRL-SH-L.  Started typing www.t
     (31673627)	Comments: Hit CTRL-O.  Escaped (ESC).  Hit CTRL-SH-L.  Started typing and it
     (31672862)	URL:
Comments: just typing in the start of a URL into the location bar


17 years ago
Keywords: crash, topcrash
Not XML, trying autocomplete...
Assignee: heikki → hewitt
Component: XML → XP Apps: Autocomplete
QA Contact: petersen → blake 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

Comment 3

17 years ago
Joe,et al- is this on the radar to resolve in time for the next release?

Comment 4

17 years ago
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

Comment 5

17 years ago
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

Comment 6

17 years ago
wait, the one other possibility is that AssignFromReadable isn't handling an
empty string well. Continuing to investigate, but adding scc to the list

Comment 7

17 years ago
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.

Comment 8

17 years ago
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:

and this code looks reasonable. maybe the fact that we're returning the value,
rather than assigning it to another variable?

Assignee: jband → dbradley

Comment 9

17 years ago
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

Comment 10

17 years ago
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.

Comment 11

17 years ago
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

Again if someone can reproduce this, I'd be interested knowing the values of the
parameters I stated above.

Comment 12

17 years ago
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

Comment 14

17 years ago
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.

Comment 15

17 years ago
My fishing with Purify did not uncover any problems.

Comment 16

17 years ago
*** Bug 99528 has been marked as a duplicate of this bug. ***

Comment 17

17 years ago
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]

Comment 18

17 years ago
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.

Comment 19

17 years ago
Here are some recent comments from the MozillaTrunk topcrash report for crashes
with the nsXULAttributeValue::SetValue stack signature:

Source File :
line : 94
     (36057781)	Comments: Trying to start it
     (36031202)	URL:
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:
Comments: Loading Communicator.
     (35973967)	URL:
Comments: Loading Communicator.
     (35973949)	URL:
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]

Comment 20

17 years ago
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

Comment 21

17 years ago
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?  


17 years ago
Summary: Trunk crash [@ nsXULAttributeValue::SetValue][@ nsAString::AssignFromReadable] → Trunk & M095 crash [@ nsXULAttributeValue::SetValue][@ nsAString::AssignFromReadable]

Comment 22

17 years ago
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 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.

Comment 24

17 years ago
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 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?

Comment 26

17 years ago
Mike: that is a good point. We need to include some check to make sure we are
not installing over an older existing installation.

Comment 27

17 years ago
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?

Comment 28

17 years ago
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.
Last Resolved: 17 years ago
Component: XP Apps: Autocomplete → Installer
Resolution: --- → INVALID

Comment 29

17 years ago
*** 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.