Closed Bug 146033 Opened 22 years ago Closed 22 years ago

New M1RC3 crashes at [@ nsLocalFile::GetLeafName]

Categories

(Core :: XPConnect, defect, P1)

Product:
Core
Component:
XPConnect
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
mozilla1.0.1

People

(Reporter: greer, Assigned: darin.moz)

Details

(Keywords: crash)

Crash Data

Logging this one preemptively - This signature only has 2 incidents in
Talkback for branch build 2002051909. 
 Darin, Shiva tells me to assign it to you for the first look. Please move it to
whomever deserves it. (No user comments, yet.)


	 nsLocalFile::GetLeafName
[d:\builds\seamonkey\mozilla\xpcom\io\nsLocalFileWin.cpp  line 2251] 
	 XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp 
line 106] 
	 XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp  line 2028] 
	 XPC_WN_GetterSetter
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp 
line 1299] 
	 js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 790] 
	 js_InternalInvoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 881] 
	 js_GetProperty
[d:\builds\seamonkey\mozilla\js\src\jsobj.c  line 2517] 
	 js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 2576] 
	 js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 806] 
	 nsXPCWrappedJSClass::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp  line 1195] 
	 nsXPCWrappedJS::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp  line 430] 
	 PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp 
line 117] 
	 SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp 
line 139] 
	 XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp 
line 106] 
	 XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp  line 2028] 
	 XPC_WN_CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp 
line 1267] 
	 js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 790] 
	 js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 2744] 
	 js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 806] 
	 js_InternalInvoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 881] 
	 JS_CallFunctionValue
[d:\builds\seamonkey\mozilla\js\src\jsapi.c  line 3426] 
	 nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp  line 1019] 
	 nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp  line 182] 
	 nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp  line
1220] 
	 nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp  line
1902] 
	 GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp  line 727] 
	 DocumentViewerImpl::LoadComplete
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp  line 1436] 
	 nsDocShell::EndPageLoad
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp  line 3886] 
	 nsWebShell::EndPageLoad
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp  line 731] 
	 nsDocShell::OnStateChange
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp  line 3803] 
	 nsDocLoaderImpl::FireOnStateChange
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 1105] 
	 nsDocLoaderImpl::doStopDocumentLoad
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 744] 
	 nsDocLoaderImpl::DocLoaderIsEmpty
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 642] 
	 nsDocLoaderImpl::OnStopRequest
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 573] 
	 nsLoadGroup::RemoveRequest
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp  line 531] 
	 nsJARChannel::OnStopRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp  line 612] 
	 nsOnStopRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp  line 213] 
	 PL_HandleEvent
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 597] 
	 PL_ProcessPendingEvents
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 530] 
	 _md_EventReceiverProc
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 1078] 
	 nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp  line 451] 
	 main1
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1473] 
	 main
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1809] 
	 WinMain
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1827] 
	 WinMainCRTStartup()  
	 KERNEL32.DLL + 0xd326 (0x77e8d326)
hmm.. javascript code should not be calling nsIFile::leafName... that attribute
is unscriptable.
Status: NEW → ASSIGNED
Keywords: crash
Priority: -- → P1
Target Milestone: --- → mozilla1.0.1
yikes!  scratch my last comment... nsIFile::leafName is what should be called
from JS.
hmm.. since the signature changed recently for nsIFile::leafName from

  NS_IMETHOD GetLeafName(char **);

to

  NS_IMETHOD GetLeafName(nsAString &);

i wonder if this crash might be explained by someone installing a newer mozilla
build over top an older build.  that has resulted in this sort of "javascript
calling a method" crashes in the past.
It does look like thats the case. The addressed passed in, looks to be an
address of a pointer rather than an address of a string object. The first 4
bytes pointed to are zero. It's either that, or a deleted string, but I think a
deleted string would look different.
so marking WONTFIX (i guess) since there's nothing we can do about this... short
of some kind of install time check / warning.

dveditz: are you aware of this problem?  it keeps showing up every now and again
after some such API change.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
For the time being, marking Verified Wontfix. But shouldn't this bug
actually be reopened and assigned to the Installer component? 

That is, shouldn't the install process prevent this problem? 
Or is that not possible?
Status: RESOLVED → VERIFIED
I think ideally we should just create a new bug against installer if there isn't
one already there. At first glance it doesn't seem like a big deal to check for
an existing install and at least warn the user, but then I'm not at all familiar
with the installer code and capabilities.

I think it's worth the effort. I've hit in the neighborhood of six bugs I think,
that can be traced back to this. I'm sure a good amount of time was spent by
others before it got to me, so I would think it would be a good payoff if it's a
relatively easy check to add in the installer.

And these crashes happen pretty quick, while the people didn't follow
instructions, it probably steal leaves them with a bad perception of the browser
release.
Darin pointed out to me that the problem may in fact be caused
by people unzipping Mozilla into their existing Mozilla directory.

That is, they are NOT using the installer -
i talked to dbradley about this and he's going to look into adding a runtime
check at startup to test whether component.reg and xpti.dat are older than
mozilla.exe.  if so, we should blow away component.reg and xpti.dat to avoid
being out-of-sync.
Another source of this could be 3rd-party add-ons, such as the ones from MozDev.
A leftover spellchecker module is currently causing some ugly "entry point not
found" windows alert boxes.

After an install we automatically cause an autoreg on the next startup (unless,
of course, it has regressed). If people are unzipping they could get zapped by
this kind of problem. Adding more stats to startup won't make you popular in the
performance group, though.

There used to be a build ID check at startup, where the code made sure a build
ID stored in component.reg matched the current xpcom.dll (or might have been
xpinstal.dll -- dp may have had me move it). If they didn't match an autoreg was
performed. Has that check gone away, too?
Do we have email addresses for the victims here? I'd like to get an "ls -l
*.xpt" of their components directory to see which ones don't match. That will
let us know whether we're dealing with our own leftovers or 3rd party stuff.
Discovering the true cause might help us figure out an approach to helping folks
avoid it.
Dan - yes, we have one email address. I will send it to you privately.
Most all of the cases I've come across, like this one, have been the result of
interface changes we have made. But that's a good point, third party xpcom based
components could suffer the same fate if they didn't trigger a regxpcom, which I
think most good players do.

The build ID check would be a good solution as well, I would have to believe
it's been removed or otherwise disabled, given the behavior we've seen.
This familiar looking stack is showing up in the branch builds leading up to
M1RC3. Different signature, but the same problem, yes?

	 nsLocalFile::GetPath
[d:\builds\seamonkey\mozilla\xpcom\io\nsLocalFileWin.cpp  line 2274]
	 XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp 
line 106]
	 XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp  line 2028]
	 XPC_WN_GetterSetter
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp 
line 1299]
	 js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 790]
	 js_InternalInvoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 881]
	 js_GetProperty
[d:\builds\seamonkey\mozilla\js\src\jsobj.c  line 2517]
	 js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 2576]
	 js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 806]
	 nsXPCWrappedJSClass::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp  line 1195]
	 nsXPCWrappedJS::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp  line 430]
	 PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp 
line 117]
	 SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp 
line 139]
	 XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp 
line 106]
	 XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp  line 2028]
	 XPC_WN_CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp 
line 1267]
	 js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 790]
	 js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 2744]
	 js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 806]
	 js_InternalInvoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 881]
	 JS_CallFunctionValue
[d:\builds\seamonkey\mozilla\js\src\jsapi.c  line 3426]
	 nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp  line 1019]
	 nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp  line 182]
	 nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp  line
1220]
	 nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp  line
1902]
	 GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp  line 727]
	 DocumentViewerImpl::LoadComplete
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp  line 1436]
	 nsDocShell::EndPageLoad
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp  line 3887]
	 nsWebShell::EndPageLoad
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp  line 731]
	 nsDocShell::OnStateChange
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp  line 3801]
	 nsDocLoaderImpl::FireOnStateChange
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 1112]
	 nsDocLoaderImpl::doStopDocumentLoad
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 771]
	 nsDocLoaderImpl::DocLoaderIsEmpty
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 669]
	 nsDocLoaderImpl::OnStopRequest
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp  line 600]
	 nsLoadGroup::RemoveRequest
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp  line 531]
	 nsJARChannel::OnStopRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp  line 612]
	 nsOnStopRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp  line 213]
	 PL_HandleEvent
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 597]
	 PL_ProcessPendingEvents
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 530]
	 _md_EventReceiverProc
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 1078]
	 KERNEL32.DLL + 0x24407 (0xbff94407)
	 0x00648bfa
 
 	Source File :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/io/nsLocalFileWin.cpp
line : 2274
Yes, it is the same problem. I checked the talkback assembler info and it is the
same type of crash.
RE: Comment #10, interface versioning would address this, maybe versioning is
the ultimate answer.
Crash Signature: [@ nsLocalFile::GetLeafName]
You need to log in before you can comment on or make changes to this bug.