Closed Bug 8830 Opened 26 years ago Closed 26 years ago

m7 start crash in xpcom

Categories

(Core :: XPCOM, defect, P2)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: chofmann, Assigned: dp)

References

Details

(Keywords: crash, Whiteboard: incendent id 10303561)

From the M7 talkback reports. At least one instance... Windows 95 4.0 build 67306684 Available Total Physical Memory: 1.5 MB 96.0 MB bit low on memory... starts up, then crashes Call Stack: (Signature = nsFileURL::operator= 595b604f) nsFileURL::operator= [d:\builds\seamonkey\mozilla\xpcom\io\nsFileSpec.cpp, line 576] nsFileURL::operator= [d:\builds\seamonkey\mozilla\xpcom\io\nsFileSpec.cpp, line 593] nsFileURL::nsFileURL [d:\builds\seamonkey\mozilla\xpcom\io\nsFileSpec.cpp, line 514] nsBookmarksService::ReadBookmarks [d:\builds\seamonkey\mozilla\xpfe\components\bookmarks\src\nsBookmarksService.cp p, line 1242] nsBookmarksService::Init [d:\builds\seamonkey\mozilla\xpfe\components\bookmarks\src\nsBookmarksService.cp p, line 938] NS_NewBookmarksService [d:\builds\seamonkey\mozilla\xpfe\components\bookmarks\src\nsBookmarksService.cp p, line 966] nsGenericFactory::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsGenericFactory.cpp, line 54] nsComponentManagerImpl::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsComponentManager.cpp, line 1078] nsComponentManager::CreateInstance [d:\builds\seamonkey\mozilla\xpcom\components\nsRepository.cpp, line 68] nsServiceManagerImpl::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 244] nsServiceManagerImpl::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 384] nsServiceManager::GetService [d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 488] ServiceImpl::GetDataSource [d:\builds\seamonkey\mozilla\rdf\base\src\nsRDFService.cpp, line 893] RDFXULBuilderImpl::CreateBuilder [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFXULBuilder.cpp, line 2618] RDFXULBuilderImpl::CreateXULElement [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFXULBuilder.cpp, line 2265] RDFXULBuilderImpl::CreateOrReuseElement [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFXULBuilder.cpp, line 1872] RDFXULBuilderImpl::AppendChild [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFXULBuilder.cpp, line 1679] RDFXULBuilderImpl::CreateContents [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFXULBuilder.cpp, line 696] XULDocumentImpl::CreateContents [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 2540] RDFElementImpl::EnsureContentsGenerated [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 2581] RDFElementImpl::ChildCount [d:\builds\seamonkey\mozilla\rdf\content\src\nsRDFElement.cpp, line 1495] nsCSSFrameConstructor::ProcessChildren [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 710] nsCSSFrameConstructor::ConstructXULFrame [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 2953] nsCSSFrameConstructor::ConstructFrame [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 3680] nsCSSFrameConstructor::ProcessChildren [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 716] nsCSSFrameConstructor::ConstructXULFrame [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 2953] nsCSSFrameConstructor::ConstructFrame [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 3680] nsCSSFrameConstructor::ProcessChildren [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 716] nsCSSFrameConstructor::ConstructDocElementFrame [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 1961] nsCSSFrameConstructor::ContentInserted [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 4144] StyleSetImpl::ContentInserted [d:\builds\seamonkey\mozilla\layout\base\src\nsStyleSet.cpp, line 800] PresShell::InitialReflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 867] XULDocumentImpl::StartLayout [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 3946] XULDocumentImpl::EndLoad [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 1851] CWellFormedDTD::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsWellFormedDTD.cpp, line 308] nsParser::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 512] nsParser::ResumeParse [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 868] nsParser::EnableParser [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 587] XULContentSinkImpl::DoneLoadingScript [d:\builds\seamonkey\mozilla\rdf\datasource\src\nsXULContentSink.cpp, line 1516] nsDocumentBindInfo::OnStopBinding [d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 1601] OnStopBindingProxyEvent::HandleEvent [d:\builds\seamonkey\mozilla\network\module\nsNetThread.cpp, line 594] StreamListenerProxyEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\network\module\nsNetThread.cpp, line 474] PL_HandleEvent [plevent.c, line 492] PL_ProcessPendingEvents [plevent.c, line 453] _md_EventReceiverProc [plevent.c, line 881] KERNEL32.DLL + 0x35d9 (0xbff735d9) KERNEL32.DLL + 0x2222f (0xbff9222f)
similar stack and comment from a user running windows 2000 First time starting in Win2000pro. Did crash immeadiately before the browser window appeared. Windows NT 5.0 build 2031. this user had more virtual mem. so we should be able to rule that out... Available Total Physical Memory: 99.1 MB 192.0 MB crash occured about 15 seconds into start up. Seconds Since Last Crash: 15 seconds (00:00:15)
Another user on win95. It crashed upon running apprunner. There were no error messages in the console and nothing started. It has done this on the daylies since and including M6. Ever since the profile stuff got added.
last user might have been running on a slower system. took them 89 second to hit the crash.. Seconds Since Last Crash: 89 seconds (00:01:29)
Severity: normal → major
Status: NEW → ASSIGNED
Priority: P3 → P2
mmh! Beth, can you try to reproduce this at all.
The stack trace is a line number off. Dont know if that is normal. What we are trying to do is to get the name of the ie favourites file. This code if windows specific. There is no obvious code issue here. We hit this code in a lot of places. My best guess is something about the IE favourites file not being there. There is no null check being made. So if say IE is not installed on the machine or (otherwise), this can happen. Can testing try reproducing the crash with the above situations.
From dp comments :- The stack trace is a line number off. Dont know if that is normal. It can't be normal. If it is then the stack trace will become unusable. linenumbers provided in the stack trace points to particular build and it doesn't apply to other builds. It think this crash happened in m7 milestone. Please verify the line numbers matching the crash with m7 milestone source tree.
I did that. The file xpcom/io/nsFileSpec.cpp was last changed 6/3/99 M7 should have happened certainly after that. Namachi, can you make sure my inference is correct by checking on the file.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
I cant make sense of this stack trace. Cant reproduce. Hence I am going to say WORKSFORME.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
A lot more reports on this. Reopening.
Status: REOPENED → ASSIGNED
Assignee: dp → waterson
Status: ASSIGNED → NEW
Waterson, since this keyed off bookmarks, could you make sure we aren't passing in NULL.
Target Milestone: M8
putting on the m8 radar
Protecting filespec against null is essential. Hence taking over bug.
Assignee: waterson → dp
*** Bug 9055 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Sill working on this one...
Got a fix...
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Checked in a fix to protect against NULL. This is a code fix. Unless you can make it crash earlier, I dont think testing can verify this.
build 1999070808 works okay on my machine (for the first time since some time before M5!) Thank you for your help!
Status: RESOLVED → VERIFIED
Awesome. Thanks Marcus. Hail Marcus! I am marking this bug verified.
Status: VERIFIED → REOPENED
Target Milestone: M8 → M10
I got this bug on the recent M10. apprunner started up and right after "startpage = www.mozilla.org" I got a GPF APPRUNNER caused an invalid page fault in module XPCOM.DLL at 014f:60ad1510. Registers: EAX=00000000 CS=014f EIP=60ad1510 EFLGS=00010202 EBX=01245910 SS=0157 ESP=0063eebc EBP=0063efc4 ECX=000000a1 DS=0157 ESI=0063eff4 FS=2aff EDX=8167eca4 ES=0157 EDI=0063eff0 GS=0000 Bytes at CS:EIP: 80 38 00 74 08 50 8b ce e8 1e fa ff ff 5e c9 c3 Stack dump: 0063eff4 00000100 0000010c bff798cf 816b3960 0000010c 780012b1 0000003f 00000100 0000010c bff798cf 0000003f 0063ef88 00fe4730 bff798cf 816b3960 rebooting... same thing, slightly different registers: EBX=0082d510 FS=407f EDX=8168ccf4 and a different stack dump: Stack dump: 0063eff4 00000100 0000010c bff798cf 8167119c 0000010c 780012b1 0000003f 00000100 0000010c bff798cf 0000003f 0063ef88 02fd59d0 bff798cf 8167119c I tried the xpcom logging instructions found in problem 9055 but the first two lines produced syntax errors.
Resolution: FIXED → ---
Clearing Fixed resolution due to reopen
Target Milestone: M10 → M11
Moving to M11...M10 is out the door.
forgot to add myself to CC
mmh! I would really like an xpcom log. Here is how you do it. I think you might have gotten the unix instructions and that would have given you the syntax error. Start->Run... - Type in cmd - You will get a DOS command shell window - cd c:\Program Files\Netscape\Seamonkey or whereever apprunner.exe is installed - Type in set NSPR_LOG_MODULES=nsComponentManager:5 set NSPR_LOG_FILE=xpcom.log - Start apprunner by typing in .\apprunner Let me know if there is trouble in getting the log file.
Status: REOPENED → ASSIGNED
QA Contact: beppe → gerardok
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
I am going to mark this bug FIXED. Please file a new bug if m10 coredump happens even if we delete the moz registry.
Adding crash keyword
Keywords: crash
Well, we don't crash on startup, so verifying - win32 comm 2001052204 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.