Overview Description: Cannot install daily seamonkey build due to crash on profile creation. Both new and migrating causes a problem. Steps to Reproduce: 1) Download commercial 1999-11-17-17-M12/ build on WinNT machine. 2) Start installation process 3) Select to migrate a profile or create a new one. Actual Results: Crash in Dr. Watson. Talkback window comes up. Expected Results: Installation to complete, and ability to use product. Build Date & Platform Bug Found: 1999-11-17-17-M12/ - WinNT Additional Builds and Platforms Tested On: None Additional Information: See leger for more info

Adding Talkback stack trace from crash, Incident 1001099 Trigger Type: Program Crash Trigger Reason: Access violation Call Stack: (Signature = JS_ArenaAllocate d5d0b842) JS_ArenaAllocate [d:\builds\seamonkey\mozilla\js\src\jsarena.c, line 108] AllocSrcNote [d:\builds\seamonkey\mozilla\js\src\jsemit.c, line 2356] js_NewSrcNote [d:\builds\seamonkey\mozilla\js\src\jsemit.c, line 2388] js_EmitTree [d:\builds\seamonkey\mozilla\js\src\jsemit.c, line 583] js_EmitTree [d:\builds\seamonkey\mozilla\js\src\jsemit.c, line 1668] js_EmitFunctionBody [d:\builds\seamonkey\mozilla\js\src\jsemit.c, line 466] js_EmitTree [d:\builds\seamonkey\mozilla\js\src\jsemit.c, line 600] js_Parse [d:\builds\seamonkey\mozilla\js\src\jsparse.c, line 295] CompileTokenStream [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2277] JS_CompileUCScriptForPrincipals [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2355] JS_EvaluateUCScriptForPrincipals [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2715] nsJSContext::EvaluateString [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 228] nsXULDocument::EvaluateScript [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 4670] nsXULDocument::OnUnicharStreamComplete [d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 4629] nsUnicharStreamLoader::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\base\src\nsUnicharStreamLoader.cpp, line 128] nsChannelListener::OnStopRequest [d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 1343] nsFileChannel::OnStopRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\file\src\nsFileChannel.cpp, line 452] nsOnStopRequestEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 326] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 174] PL_HandleEvent [plevent.c, line 538] PL_ProcessPendingEvents [plevent.c, line 499] _md_EventReceiverProc [plevent.c, line 976] USER32.dll + 0x1250 (0x77e71250) nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 489] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 586] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 677] mainCRTStartup() KERNEL32.dll + 0x1b304 (0x77f1b304) :

It crashed in the Profile Manager. Reassigning to Steve Elmer.

Grace, can you reproduce the crash? There's nothing in the stack trace to indicate the profile manager is involved. It looks more like a problem bringing up the main window.

Steve, I reinstalled this morning after seeing this bug-I had done yesterday also-with no problems. Created a profile and migrated one successfully as well. Tina, I am noticing from stack trace that you are referencing d: drive, can you tell me where you install- drive/path etc? Grace

*** Bug 19243 has been marked as a duplicate of this bug. ***

daver is seeing this with this mornings installer too. I'll take a look and see if I can figure out who to re-assign it too.

Brendan, do you think this crash could be related to the js brutal script sharing that got checked in last night? The stack trace makes me think that could be a possibility.

I am seeing the same thing in today (and yesterday's) Win32 M12 builds. I just use an existing profile. My stack trace is the same as tgrier reported. This bug needs to be reassigned to someone besides gbush. Who whould get it?

daver said he installed successfully after deleting old bits. Is anyone not removing old installations?

My brutal sharing checkin was yesterday evening, and it removed EvaluateString and EvaluateScript from XUL, splitting compilation from execution. So this crash must be due to a bug that existed yesterday, the 17th, possibly another bug in the JS engine (I fixed one recently). Unfortunately, it looks like memory corruption, even if caused by the JS engine, because JS_ArenaAllocate is getting a bad address from its data structure. I'm still waiting for that new Dell -- can someone help purify? Cc'ing bienvenu but I owe him too much already. Maybe he can refer someone else? Thanks. /be

grace: Daver still sees the crash even after deleting the old bits and re-installing.

I'm at work today with my pc jr - so you might try someone else. Waterson, putterman (though he's in a meeting)...I can try it tonight at home if no one gets to it before then.

*** Bug 19277 has been marked as a duplicate of this bug. ***

*** Bug 19282 has been marked as a duplicate of this bug. ***

Sending over to javascript folks.

Still looking for a purify buddy. Mccabe, if you get impurities that point at my recent changes, please reassign stat. Thanks, /be

I can run purify now - I'm at home. I need to update my commercial tree first, though.

adding myself to cc: since this is happening to me all the time with new profiles, existing profiles.

*** Bug 18783 has been marked as a duplicate of this bug. ***

More observations: - typical or complete installation, same problem - new profile, existing profile, same problem - renamed mozregistry.dat and users50 directory prior to installation, same problem - installation into a brand new directory, all old versions of 5.0 deleted

same problem for me on Win 98 using today/s 11/19 build.....tried with fresh profile, didn't help..

putting on PDT radar

Grace and I tried to compare our files after installation. She has a filed called "Xpcs Registry.dat" and I don't. Perhaps this has something to do with it? The next step is to find people who have this crash and see if s/he has this file in the same directory as the executable. (Just trying to grasp at straws here to make some progress to narrow down this bug.)

bienvenu was kind enough to try to reproduce, under purify and not -- no luck. David wrote: "I tried for several hours to reproduce this with Purify - I tried both a release and debug build and I didn't see any related problems, nor did I crash when not running under Purify. I did see a bunch of red in layout - I've attached some of the output for fun, but I doubt it's related. - david [W] UMR: Uninitialized memory read in memcmp {28 occurrences} Reading 6 bytes from 0x0397f0ec (1 byte at 0x0397f0f1 uninitialized) Address 0x0397f0ec is argument #1 of memcmp Address 0x0397f0ec is 212 bytes into a 23832 byte block at 0x0397f018 Address 0x0397f0ec points to a C++ new block in heap 0x03720000 Thread ID: 0x5f Error location memcmp [memcmp.asm:60] Compare1To1(char const*,char const*,UINT,int) [bufferRoutines.h:403] nsStr::Compare(nsStr const&,nsStr const&,int,int) [nsStr.cpp:609] nsCString::Compare(nsStr const&,int,int)const [nsString.cpp:1500] EntityNameComparitor::()(void *,void *) [nsHTMLEntities.cpp:60] avlInsert [nsAVLTree.cpp:213] avlInsert [nsAVLTree.cpp:215] nsAVLTree::AddItem(void *) [nsAVLTree.cpp:476] nsHTMLEntities::AddRefTable(void) [nsHTMLEntities.cpp:114] nsParserModule::Initialize(void) [nsParserModule.cpp:179] Allocation location new(UINT) [new.cpp:23] nsHTMLEntities::AddRefTable(void) [nsHTMLEntities.cpp:102] nsParserModule::Initialize(void) [nsParserModule.cpp:179] nsParserModule::GetClassObject(nsIComponentManager *,nsID const&,nsID const&,void * *) [nsParserModule.cpp:209] nsNativeComponentLoader::GetFactoryFromModule(nsDll *,nsID const&,nsIFactory * *) [nsNativeComponentLoader.cpp:1022] nsNativeComponentLoader::GetFactory(nsID const&,char const*,char const*,nsIFactory * *) [nsNativeComponentLoader.cpp:112] nsFactoryEntry::GetFactory(nsIFactory * *,nsComponentManagerImpl *) [nsComponentManager.h:207] nsComponentManagerImpl::FindFactory(nsID const&,nsIFactory * *) [nsComponentManager.cpp:1074] nsComponentManagerImpl::CreateInstance(nsID const&,nsISupports *,nsID const&,void * *) [nsComponentManager.cpp:1237] nsComponentManager::CreateInstance(nsID const&,nsISupports *,nsID const&,void * *) [nsRepository.cpp:81] RDFXMLDataSourceImpl::Refresh(int) [nsRDFXMLDataSource.cpp:897] nsChromeRegistry::LoadDataSource(nsCAutoString const&,nsIRDFDataSource * *) [nsChromeRegistry.cpp:569] nsChromeRegistry::InitializeDataSource(nsString&,nsString&,nsIRDFDataSource * *) [nsChromeRegistry.cpp:624] nsChromeRegistry::ConvertChromeURL(nsIURI *) [nsChromeRegistry.cpp:374] nsChromeProtocolHandler::NewChannel(char const*,nsIURI *,nsILoadGroup *,nsIInterfaceRequestor *,UINT,nsIURI *,nsIChannel * *) [nsChromeProtocolHandler.cpp:142] /* repeated hundreds of times */ [E] ABR: Array bounds read in nsCRT::strlen(WORD const*) {344 occurrences} Reading 2 bytes from 0x06debbbe (2 bytes at 0x06debbbe illegal) Address 0x06debbbe is 1 byte past the end of a 22 byte block at 0x06debba8 Address 0x06debbbe points to a C++ new block in heap 0x03720000 Thread ID: 0x5f Error location nsCRT::strlen(WORD const*) [nsCRT.cpp:228] nsString::Append(WORD const*,int) [nsString2.cpp:1094] nsAutoString::nsAutoString(WORD const*,int) [nsString2.cpp:2190] nsCommentNode::SetText(WORD const*,int,int) [nsCommentNode.cpp:490] nsGenericDOMDataNode::AppendData(nsString const&) [nsGenericDOMDataNode.cpp:339] nsCommentNode::AppendData(nsString const&) [nsCommentNode.cpp:57] SinkContext::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:1553] HTMLContentSink::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:2644] CNavDTD::HandleCommentToken(CToken *) [CNavDTD.cpp:1719] CNavDTD::HandleToken(CToken *,nsIParser *) [CNavDTD.cpp:736] Allocation location new(UINT) [new.cpp:23] nsGenericDOMDataNode::AppendData(nsString const&) [nsGenericDOMDataNode.cpp:320] nsCommentNode::AppendData(nsString const&) [nsCommentNode.cpp:57] SinkContext::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:1553] HTMLContentSink::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:2644] CNavDTD::HandleCommentToken(CToken *) [CNavDTD.cpp:1719] CNavDTD::HandleToken(CToken *,nsIParser *) [CNavDTD.cpp:736] CNavDTD::BuildModel(nsIParser *,nsITokenizer *,nsITokenObserver *,nsIContentSink *) [CNavDTD.cpp:529] nsParser::BuildModel(void) [nsParser.cpp:1030] nsParser::ResumeParse(nsIDTD *,int) [nsParser.cpp:956] nsParser::OnDataAvailable(nsIChannel *,nsISupports *,nsIInputStream *,UINT,UINT) [nsParser.cpp:1306] nsDocumentBindInfo::OnDataAvailable(nsIChannel *,nsISupports *,nsIInputStream *,UINT,UINT) [nsDocLoader.cpp:1289] nsChannelListener::OnDataAvailable(nsIChannel *,nsISupports *,nsIInputStream *,UINT,UINT) [nsDocLoader.cpp:1484] nsHTTPResponseListener::OnDataAvailable(nsIChannel *,nsISupports *,nsIInputStream *,UINT,UINT) [nsHTTPResponseListener.cpp:175] nsOnDataAvailableEvent::HandleEvent(void) [nsAsyncStreamListener.cpp:416] [E] IPR: Invalid pointer read in nsCRT::strlen(WORD const*) {788 occurrences} Reading 2 bytes from 0x06debbce (2 bytes at 0x06debbce illegal) Address 0x06debbce points into a HeapAlloc'd block in unallocated region of heap 0x03720000 Thread ID: 0x5f Error location nsCRT::strlen(WORD const*) [nsCRT.cpp:228] nsString::Append(WORD const*,int) [nsString2.cpp:1094] nsAutoString::nsAutoString(WORD const*,int) [nsString2.cpp:2190] nsCommentNode::SetText(WORD const*,int,int) [nsCommentNode.cpp:490] nsGenericDOMDataNode::AppendData(nsString const&) [nsGenericDOMDataNode.cpp:339] nsCommentNode::AppendData(nsString const&) [nsCommentNode.cpp:57] SinkContext::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:1553] HTMLContentSink::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:2644] CNavDTD::HandleCommentToken(CToken *) [CNavDTD.cpp:1719] CNavDTD::HandleToken(CToken *,nsIParser *) [CNavDTD.cpp:736] [E] ABR: Array bounds read in memcpy {15 occurrences} Reading 130 bytes from 0x06debba8 (108 bytes at 0x06debbbe illegal) Address 0x06debba8 is at the beginning of a 22 byte block Address 0x06debba8 points to a C++ new block in heap 0x03720000 Thread ID: 0x5f Error location memcpy [memcpy.asm:109] CopyChars2To2(char *,int,char const*,UINT,UINT) [bufferRoutines.h:223] nsStr::Append(nsStr&,nsStr const&,UINT,int) [nsStr.cpp:172] nsString::Append(WORD const*,int) [nsString2.cpp:1097] nsAutoString::nsAutoString(WORD const*,int) [nsString2.cpp:2190] nsCommentNode::SetText(WORD const*,int,int) [nsCommentNode.cpp:490] nsGenericDOMDataNode::AppendData(nsString const&) [nsGenericDOMDataNode.cpp:339] nsCommentNode::AppendData(nsString const&) [nsCommentNode.cpp:57] SinkContext::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:1553] HTMLContentSink::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:2644] Allocation location new(UINT) [new.cpp:23] nsGenericDOMDataNode::AppendData(nsString const&) [nsGenericDOMDataNode.cpp:320] nsCommentNode::AppendData(nsString const&) [nsCommentNode.cpp:57] SinkContext::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:1553] HTMLContentSink::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:2644] CNavDTD::HandleCommentToken(CToken *) [CNavDTD.cpp:1719] CNavDTD::HandleToken(CToken *,nsIParser *) [CNavDTD.cpp:736] CNavDTD::BuildModel(nsIParser *,nsITokenizer *,nsITokenObserver *,nsIContentSink *) [CNavDTD.cpp:529] nsParser::BuildModel(void) [nsParser.cpp:1030] nsParser::ResumeParse(nsIDTD *,int) [nsParser.cpp:956] nsParser::OnDataAvailable(nsIChannel *,nsISupports *,nsIInputStream *,UINT,UINT) [nsParser.cpp:1306] nsDocumentBindInfo::OnDataAvailable(nsIChannel *,nsISupports *,nsIInputStream *,UINT,UINT) [nsDocLoader.cpp:1289] nsChannelListener::OnDataAvailable(nsIChannel *,nsISupports *,nsIInputStream *,UINT,UINT) [nsDocLoader.cpp:1484] nsHTTPResponseListener::OnDataAvailable(nsIChannel *,nsISupports *,nsIInputStream *,UINT,UINT) [nsHTTPResponseListener.cpp:175] nsOnDataAvailableEvent::HandleEvent(void) [nsAsyncStreamListener.cpp:416] [E] FMR: Free memory read in nsCRT::strlen(WORD const*) {1343 occurrences} Reading 2 bytes from 0x06c5ac58 (2 bytes at 0x06c5ac58 illegal) Address 0x06c5ac58 is at the beginning of a 2480 byte block Address 0x06c5ac58 points to a C++ new block in heap 0x03720000 Thread ID: 0x5f Error location nsCRT::strlen(WORD const*) [nsCRT.cpp:228] nsString::Append(WORD const*,int) [nsString2.cpp:1094] nsAutoString::nsAutoString(WORD const*,int) [nsString2.cpp:2190] nsCommentNode::SetText(WORD const*,int,int) [nsCommentNode.cpp:490] nsGenericDOMDataNode::AppendData(nsString const&) [nsGenericDOMDataNode.cpp:339] nsCommentNode::AppendData(nsString const&) [nsCommentNode.cpp:57] SinkContext::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:1553] HTMLContentSink::AddComment(nsIParserNode const&) [nsHTMLContentSink.cpp:2644] CNavDTD::HandleCommentToken(CToken *) [CNavDTD.cpp:1719] CNavDTD::HandleToken(CToken *,nsIParser *) [CNavDTD.cpp:736] Allocation location new(UINT) [new.cpp:23] nsSupportsArray::InsertElementAt(nsISupports *,UINT) [nsSupportsArray.cpp:181] InsertRuleByWeight [nsCSSStyleSheet.cpp:2969] nsSupportsArray::EnumerateForwards((*)(nsISupports *,void *),void *) [nsSupportsArray.cpp:356] CSSRuleProcessor::CascadeSheetRulesInto(nsISupports *,void *) [nsCSSStyleSheet.cpp:2996] CSSRuleProcessor::CascadeSheetRulesInto(nsISupports *,void *) [nsCSSStyleSheet.cpp:2991] nsSupportsArray::EnumerateForwards((*)(nsISupports *,void *),void *) [nsSupportsArray.cpp:356] CSSRuleProcessor::GetRuleCascade(nsIAtom *) [nsCSSStyleSheet.cpp:3024] CSSRuleProcessor::RulesMatching(nsIPresContext *,nsIAtom *,nsIContent *,nsIAtom *,nsIStyleContext *,nsISupportsArray *) [nsCSSStyleSheet.cpp:2789] EnumPseudoRulesMatching [nsStyleSet.cpp:702] nsSupportsArray::EnumerateForwards((*)(nsISupports *,void *),void *) [nsSupportsArray.cpp:356] StyleSetImpl::ResolvePseudoStyleFor(nsIPresContext *,nsIContent *,nsIAtom *,nsIStyleContext *,int) [nsStyleSet.cpp:730] nsPresContext::ResolvePseudoStyleContextFor(nsIContent *,nsIAtom *,nsIStyleContext *,int,nsIStyleContext * *) [nsPresContext.cpp:438] nsCSSFrameConstructor::ConstructRootFrame(nsIPresContext *,nsIContent *,nsIFrame *&) [nsCSSFrameConstructor.cpp:2379] StyleSetImpl::ConstructRootFrame(nsIPresContext *,nsIContent *,nsIFrame *&) [nsStyleSet.cpp:922] Free location delete(void *) [dbgdel.cpp:35] nsSupportsArray::InsertElementAt(nsISupports *,UINT) [nsSupportsArray.cpp:196] InsertRuleByWeight [nsCSSStyleSheet.cpp:2969] nsSupportsArray::EnumerateForwards((*)(nsISupports *,void *),void *) [nsSupportsArray.cpp:356] CSSRuleProcessor::CascadeSheetRulesInto(nsISupports *,void *) [nsCSSStyleSheet.cpp:2996] CSSRuleProcessor::CascadeSheetRulesInto(nsISupports *,void *) [nsCSSStyleSheet.cpp:2991] nsSupportsArray::EnumerateForwards((*)(nsISupports *,void *),void *) [nsSupportsArray.cpp:356] CSSRuleProcessor::GetRuleCascade(nsIAtom *) [nsCSSStyleSheet.cpp:3024] CSSRuleProcessor::RulesMatching(nsIPresContext *,nsIAtom *,nsIContent *,nsIAtom *,nsIStyleContext *,nsISupportsArray *) [nsCSSStyleSheet.cpp:2789] EnumPseudoRulesMatching [nsStyleSet.cpp:702] nsSupportsArray::EnumerateForwards((*)(nsISupports *,void *),void *) [nsSupportsArray.cpp:356] StyleSetImpl::ResolvePseudoStyleFor(nsIPresContext *,nsIContent *,nsIAtom *,nsIStyleContext *,int) [nsStyleSet.cpp:730] nsPresContext::ResolvePseudoStyleContextFor(nsIContent *,nsIAtom *,nsIStyleContext *,int,nsIStyleContext * *) [nsPresContext.cpp:438] nsCSSFrameConstructor::ConstructRootFrame(nsIPresContext *,nsIContent *,nsIFrame *&) [nsCSSFrameConstructor.cpp:2379] StyleSetImpl::ConstructRootFrame(nsIPresContext *,nsIContent *,nsIFrame *&) [nsStyleSet.cpp:922] Rick, can you bug someone in your team about these impurities? /be

May be dup of 19421 (dup'ing that way cuz 19421 has analysis and dependency on 18392). Waterson and I should have those bugs fixed by Monday. /be

Reassigning to Brendan, as he seems to be handling it.

*** This bug has been marked as a duplicate of 19421 ***

I believe this was a dup of 19421 -- someone prove me wrong and get me a purify trace if it wasn't. /be

Bug 19421 was marked fixed on 11/22. Using the Win32 build 1999-11-23-09-m12, I am still having the startup crash problem on the release builds. I don't have purify installed on my machine which is just my admin machine (not enough memory for purify, non-debugging environment). Does anyone have any other ideas that I can do to help with this problem? At the latest poll, a few people in int'l QA has this problem, external person has this problem, and few others in QA have this problem. Thanks.

I am going to reopen this bug as it still occurs in the 11/23 builds even after the duplicate bug was fixed on 11/22.

Assigning, need to reproduce under a debugger, if not under purify.

adding 98 to summary

I was trying to track down this problem and the first occurance of this bug (using mozilla build) is 1999-11-12-M12 (1999-11-11 is OK)

Thanks to shrirang, if I replace the js3250.dll file with the copy from an M11 build, I can start the application without any crashes. I've asked everyone that I can who has a debugger installed if they run into this problem. No one has so far. I've even posted to the builds newsgroup and no one has responded to me. Only select people without build environments using the release build have this problem.

Perfect! Only happens without a debugger. Here's a possibly dumb question: does this happen with commercial builds only, or both commercial and non-commercial release builds? /be

Brendan, the mozilla (non-commercial) build dated 11/29 gives the same crash on startup. Is there anything that you may be able to instrument into a release build which writes something out to the DOS window that can help narrow this down further? Maybe see which part of the code that gets touched in the js area before the crash occurs?

I'll debug this no matter what, but first I'm going to re-read (for the umpteenth time) checkins from 11/11/1999. Curse of an odd date (if not the last odd date for the next millenium). /be

*** Bug 19512 has been marked as a duplicate of this bug. ***

Suddenly it does not crash anymore (WinNT 4 SP5; no debugger/profiler/VC++; etc - and yes, I was getting the crash before) - this from a couple of days before the Y2K-test build (20000229). Marking this as WORKSFORME.

I'm reopening this bug for now, since the 1999112908 build still crashes on sevveral windows machines in the lab and on my desk. tgrier says she will verify with the 1999113008 build and update me.

If this is suddenly working in the 1130 build, we could try backing out a fix from yesterday and see if that reproduces the bug. I'm not sure which fix, so we could binary-search (back out half the fixes, the most recent half; test and repeat, etc.). But I am suspicious that the fix to 20147 fixed this bug too. Anyone have a release build and tree that we could try this in? Cc'ing leaf. /be

I don't think anyone has tried the 11/30 build yet because it is not available from the release team yet (both commercial and non-commercial). But, I'm not sure which build biswapesh_chatterjee@tcscal.co.in is using.

*** Bug 19619 has been marked as a duplicate of this bug. ***

*** Bug 20320 has been marked as a duplicate of this bug. ***

*Terse and annoyed* Bug 20147 is indeed fixed. The November 30 build, however, is not free of this cursed affliction. This numbers the - 15th? - consecutive daily build that cannot even stumble from the loading intact.

(temporary) workaround found so far: Replace js3250.dll with the one from 11/11 (or earlier) bld.

Waterson helped me by trying to reproduce this on his NT/4 300MHz and on his Win98 200MHz machines, using today's build. No crashes. He has 16-bit color, in case that matters. My 11/11 XULDOMJS_19991106_BRANCH landing had a bug in jsemit.c, which was fixed soon after 11/11. I believe there's a bug in js3250.dll, or at least a weakness there that another bug is preying on -- more likely it's just a JS bug, but a damn subtle one that won't manifest under a debug build or under purify. And I still can't see it by code inspection. Update: Waterson's trying other color-depths, getting no crash still. He also got no crash with his optimized build of Mozilla on his NT box. Ckritzer, can you reproduce this on a machine with MSVC installed, and then we can get symbols from leaf and try to dark-room debug it? Anyone on the cc list who's local and can reproduce the crash under a debugger, mail me or update the bug with your whereabouts. Thanks, /be

Crash in Win95 using 1999-12-02-11-M12 Windows build (same steps as original bug)

bienvenu and I ran a remotely mounted debug build on my system and did not get the crash. We ran today's release build the same way and got the crash on startup. David is going to do a release build with symbols for me to try.

brendan - david and I got the crash captured in a debugger for you. I have to be out for a while this morning and afternoon. Can you call me at x4420 to tell me how to reach you? You can come by my cubicle this afternoon around 3pm to investigate. Thanks!

Thanks, I'll be by at 3pm -- I'm out and about too, my cell is in phonebook. /be

another side effect i see of this bug is the Brief Title dialog (which asks for username and passwd) that i've encountered. here's a recipe for that, specifically when i cancelled saving a file (tested with 1999-12-02-11-m12 on NT, but using js3250.dll from build 1999-11-10-14 in order to work around this bug): it appears at various places (AIM, File Save..., etc) i'm trying to figger out the pattern. here's an example where i cancelled saving a file: 1. went to an ftp site (eg, sweetlou to download a zipped build), clicked on zip file to download 2. got Unknown File Type dialog, clicked Save File button. 3. didn't really wanna save it, so clicked cancel in Save File dialog. 4. Save File dialog goes away, only to replaced by the mysterious Brief Title dialog, in which nothing happens when clicking either OK or Cancel (see my last email on *that* problem ;-). here's what's in the console: DocLoaderFactory: Unable to create ContentViewer for command=view, content-type= application/x-unknown-content-type Document: Done (1.765 secs) Error loading URL ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/199 9-12-02-11-M12/mozilla-win32.zip Error: Can't load: ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/19 99-12-02-11-M12/mozilla-win32.zip (80004005) nsXULKeyListenerImpl::Init() commonDialogOnLoad JavaScript Error: ReferenceError: doSetOKCancel is not defined URL: chrome://global/content/commonDialog.js LineNo: 4 JavaScript Error: ReferenceError: doCancelButton is not defined looks like the lines "URL: chrome://global/content/commonDialog.js LineNo: 4" is what's generated by the Brief Title dialog. spoke with Shrirang, who checked commonDialog.js, and this should not be occurring --but then again, he doesn't experience 19165 on his box.

I don't understand the last comments. If using a js3250.dll file that's from an older build, you may see strangeness.

Here's a summary now: 1) Running the release build with symbols remotely from my system caused a crash in an area outside of JS. Crash is in the registry somewhere. Brendan knows details on this (and thinks it is a separate bug than reported here) 2) I copied the tree from David's system to my system (directories: rdf, js, xpcom, dom) and ran directly from my system. No crash occurs 3) I went back and tried to run a release build dated 11/29 which was crashing all the time on me. Now, that release starts up fine. 4) I went back and uninstalled MSVC 6.0. Tried to run a release build dated 11/29 (same as step 3). Release starts up fine. 5) Using today's release build, the product comes up fine again. Somewhere between installing MSVC and now, my system has "corrected" itself and no longer manifests this problem. Brendan, do you think we should try these steps on a different system which has the crash occur, but maybe this time, copy the registry file or do something else now that we have some add'l info? ckritzer - your system?

could it be that installing vc installs some system dlls that are different than the "default"? Is it the case that only people who haven't installed vc see this problem? If so, we could compare system dlls from two systems, one that works and one that doesn't.

That is a good idea. Grace - can you make a copy of your system directory and then install VC++? See if you can start a Win32 mozilla build. If yes, then it's something that VC++ installs that corrects this problem. I think everyone that has reported this problem is a non-developer; there may be others in QA who have a system with VC++ installed at one time or another and may not see this problem. (Or grace, can you let me know when you're in and we can compare our system directories? I uninstalled VC++ from my system, but not sure if the uninstall removed all files.)

Cc'ing a trio of Windows and MSVC gurus. /be

The XPCOM crash bug I saw on lchiang's machine is bug 20777. /be

Lisa, not sure what you're looking for about my system...info? Config? Do ya need the System and/or Registry? Happy to provide anything you need, just want some specifics! <grin>

*** Bug 20629 has been marked as a duplicate of this bug. ***

From Grace who installed MSVC: "Yes, I got seamonkey to run. I did not uninstall yet. I will do that first thing in the morning. I have listings from before and after of the system directories. Will keep you posted."

From r.hendriks@mc.ibas.nil who emailed me and told me that he was having the same crash with Mozilla. Then, he installed Adobe Acrobat reader which added the following two files to his system directory: mfc42.dll and msvcp50.dll and now he no longer gets a crash on startup with Mozilla in js. Grace - can you see if these two files make a difference for you?

re: Adobe Acrobat Reader: which version? i had installed v4.0 (on NT) on 1 december, but i had/have been experiencing this bug before and after that date...

(My original bug 19619 was marked as a dupe of this bug) I used to get this crash a long time ago, it went away (not sure when), and has come back in a nightly shortly after M11. I had much detail in the 19619 if somone wants to look there at that crash info. I don't have VC++ or any other compilers like was mention by a few here. I do have Adobe Acrobat 4.0 installed. I always delete the old mozilla directory, and the mozilla registry DAT file in the Windows directory (Win95). I run mozilla.exe go though the profile creation. After I hit "Finished" in the profile creation I get: MOZILLA caused an invalid page fault in module JS3250.DLL at 014f:609c0537. Registers: EAX=140480d9 CS=014f EIP=609c0537 EFLGS=00010282 EBX=000000d0 SS=0157 ESP=0063f608 EBP=0063f614 ECX=0000001a DS=0157 ESI=0063f868 FS=328f EDX=0063f8d0 ES=0157 EDI=00000000 GS=0000 Bytes at CS:EIP: 88 18 0f b6 99 84 b5 9e 60 85 db 7e 1a 6a 00 56 Stack dump: 00959ca0 0063f868 00735720 0063f714 609bdd7d 00959ca0 0063f868 0000001a 00959ca0 0063f868 00735720 0063f8f0 006d43e0 0063f67c 00000000 609d4d1d ============== The DOS console shows: nNCL: registering deferred (0) calling loadpage... startPage:: newProfile1_1 got a request got a request ============================== The first run does creat the mozilla registry in my Windows directory. Rerunning mozilla.exe crashes with the same message, but the DOS console only shows: nNCL: registering deferred (0) ===== If anyone wants me to try anything to help determin where this bug is coming from let me know. I hope some of the above helps.

I installed VC++6.0 and was able to run seamonkey (12/06 build). I uninstalled and did used Windiff to see files that were changed/added to system directory. See attachment. I do not have acrobat reader on this machine (do have on my WinNT machine where I have not experienced this problem)

This could be a case of us using corrupted memory or memory that isn't ours. We can possibly get this situation to occur or rather be caught if we turn on the CRT memory checking. This can be done in a debug build by turning on line http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsAppRunner.cpp#495.

changing QA contact to correct contact for component

Adding self to cc: list. Noticed this today on Windows 95 using the 1999120712 build; didn't happen using the same build on Windows 98. I'm curious: those of you who are experiencing this bug: are you using Windows 95, 98, or NT? Thanks!

D'oh! Please ignore that last comment. Took the time to read *every* comment here, and yes, it's on all Windows. Sorry!

Grace - checked with bienvenu. Try this to narrow down the problem. Backup your system directory once again. Copy all the ms*.* files from f: (before msvc) back to c:. Restart your computer and try to launch seamonkey. If ok, then copy more files back to c:. If not ok, then you can narrow down further to one or more of the ms*.* files.

The workaround (copying js3250.dll from an M11 build) for bug # 19165 works fine for me... ONCE. I thought I'd keep the M11 build in a folder, so I can copy that js3250.dll into the Seamonkey directory each time I re-install. However, the file seems to be good only for one copy -- I have to go get a *fresh* js3250.dll/M11 file from the server and copy IT into my Seamonkey directory every time. If anyone wants to see this in action (I get an all-new error message, too!), let me know and come on by.

*** Bug 14245 has been marked as a duplicate of this bug. ***

leaf, what mscv dll's are we currently packaging with the win32 builds? lets try feeding those to verah to see if that resolves the problems. verah what do you see if you do a dir command in the windows system directory... anything like this? C:\WINDOWS\SYSTEM>dir msvc*.* Volume in drive C is OMNIBOOK Volume Serial Number is 1275-11DB Directory of C:\WINDOWS\SYSTEM MSVCRT20 DLL 253,952 08-24-96 11:11a MSVCRT20.DLL MSVCIRT DLL 77,878 06-17-98 12:00a msvcirt.dll MSVCP50 DLL 565,760 01-22-97 9:26p MSVCP50.DLL MSVCRT40 DLL 326,656 05-31-98 12:00a MSVCRT40.DLL MSVCRT DLL 254,005 06-17-98 12:00a MSVCRT.DLL MSVCIRTD DLL 94,285 06-17-98 12:00a MSVCIRTD.DLL MSVCRTD DLL 385,100 06-17-98 12:00a MSVCRTD.DLL MSVCP60D DLL 516,173 06-17-98 12:00a MSVCP60D.DLL MSVCIRTD PDB 402,432 06-17-98 12:00a MSVCIRTD.PDB MSVCRTD PDB 1,811,456 06-17-98 12:00a MSVCRTD.PDB MSVCP60D PDB 1,442,816 06-17-98 12:00a MSVCP60D.PDB MSVCRT PDB 2,434,048 06-17-98 12:00a MSVCRT.PDB MSVCIRT PDB 574,464 06-17-98 12:00a MSVCIRT.PDB MSVCP60 PDB 1,999,872 06-17-98 12:00a MSVCP60.PDB MSVCP60 DLL 401,462 06-17-98 12:00a MSVCP60.DLL 15 file(s) 11,540,359 bytes

Vidur and I looked at the problem to see if we could narrow it down. We determined that: - if you delete mozregistry.dat the profile wizard comes up and lets you create a profile - viewer runs okay on the machine, and we are able to load network files as well as local files That leads to us to think it's not xul, necko, or layout that is where the problem occurs. Unfortunately with a release mode build we can't easily tell the problem occurs

I listed my system directory on a computer that has this problem and all I get is as follows: Directory of C:\WINNT\system 18/09/96 15:58 253,952 MSVCRT20.DLL 18/09/96 15:58 326,656 MSVCRT40.DLL 2 File(s) 580,608 bytes 4,763,767,808 bytes free I have also found viewer.exe to very unreliable on such machines.

When I launch today's (1999120808) mozilla build on Win98, before it crashes I get the following output in the console window: nNCL: registrering deferred (0) Poxy Configuration: no proxy initialization error: Can't load class netscape/javascript/JSUtil As far as I can tell, the path netscape/javascript/ doesn't exist...and if JSUtil is a file, it doesn't exist either. Anyone else get this?

According to depends.exe (a handy tool you can download from http://msdn.microsoft.com/library/techart/samples/5289.exe), the mozilla.exe application is only dependent (of the file chofmann/leaf mentioned) on the msvcrt.dll file (so, in theory, this is the only file we should worry about, right? ). Here's what I found: cpratt - no crash. msvcrt.dll file present os version 6.00.8168.0 lchiang - no crash. msvcrt.dll file present is version 6.00.8168.0 ckritzer - crashes. msvcrt.dll file present is version 5.00.7303 I'm going upstairs now to see if replacing the older file with the newer one will get the build to launch... I'll update this in about 15 minutes. thanks!

I was right. Here's what you need to do (this is given Windows 9x): - Obtain a copy of the newer MSVCRT.DLL file. (I'll try to tell you where later on. Internally, please contact me directly.) - Once you've got it, rename it MSVCRT.NEW and copy it into c:\windows\system (assuming that's what your Windows directory is). - Reboot into DOS (select Start | Restart in MS-DOS mode). - Change into the c:\windows\system folder. - Type REN MSVCRT.DLL MSVCRT.OLD . - Type REN MSVCRT.NEW MSVCRT.DLL . - Type EXIT . - Windows will now reboot. When it's finished, you can run Mozilla without crashing. Ultimately I suppose the installer will have to detect outdated MSVCRT.DLL files & upgrade them, yes?

Yes, absolutely the installer should have installed the newer version of the MSVCRT.DLL file

I think downloading and running this might do the fix for the time being: http://support.microsoft.com/download/support/mslfiles/Vbrun60.exe I'm currently testing it with some Netscape internal QA folk.

OK, please disregard that last remark. The URL you absolutely need to visit in order to update Windows to run Mozilla is this: http://agent.microsoft.com/windows98/downloads/contents/wurecommended/s_wufeatur ed/libraries/ Honest. This is the US English version; other languages are available.

So, should we turn this bug report (or open a new one) for the installer checking for the newer .dll file and installing it if needed.

http://support.microsoft.com/support/kb/articles/Q197/2/98.ASP provides details about the Microsoft Libraries Update. I haven't successfully been able to install the update, however; for the time being, manually replacing the MSVCRT.DLL file with the correct version has been working fine.

MSVCRT.DLL is not the only file we require or need to ship. It may be the one affecting this crash, but we also need at least MSVCIRT.DLL too. At least one of our .exes requires IMAGEHLP.DLL, but it might be a test program we can ignore. There could easily be others since we load our components dynamically. Isn't there another bug on shipping the MS redistributables? We should link the two.

When I do Windows\System>MSVC*.* on my machine, I just get these six: MSVCRT20 DLL MSVCRT40 DLL MSVCP50 DLL MSVCIRT DLL MSVCRT10 DLL MSVCRT DLL

I have the updated scripts on my machine, tested, and ready to be checked in. I've got the two files as well: msvcrt.dll msvcirt.dll All I need is to coordinate with release eng on where these two binary files should be checked into.

*** Bug 21269 has been marked as a duplicate of this bug. ***

Through much trial and error, I've found that this is the best way to update your libraries: - Launch Communicator - Go to http://www.microsoft.com/Windows98/downloads/contents/WURecommended/S_WUFeatured /Libraries/Default.asp - Follow the directions and agree to the license. Eventually, you will download a file called SPEU.EXE. Download it to your desktop. - Open a command prompt. - Navigate to the location of SPEU.EXE. - Type the following without the quotes: "SPEU /t:c:\windows\desktop /c" - (you can also replace c:\windows\desktop with any other valid path) - This will extract a bunch of a files. - Double-click SETUP.EXE to launch the installer. - Follow the instructions and reboot. Sorry it's so difficult... just opening speu.exe doesn't seem to do anything, so you've got to follow the complete instructions here!

The updated install and build scripts to install the MS files have been checked in to both the ns and mozilla trees. I'm going to reassign this bug to leaf because it's now up to him to make sure the files in question get to the proper staging areas, then into the .xpi archives (as he and I previously discussed). The versions of the files that leaf will use are: msvcrt.dll - 6.0.8168.0 msvcirt.dll - 6.0.8168.0 If this is incorrect, please let us know.

Followed instructions as per "Additional Comments From cpratt@netscape.com 1999-12-09 13:25" (although...oddly, my msvcrt.dll version remains 5.00.7303) Deleted previous installation & Users 50 directories, and mozregistry.dat. Installed 99-12-09 win32 version of mozilla, and had the same crash. Debug info follows: DOS window: nNCL: registering deferred (0) WEBSHELL+ = 1 WEBSHELL+ = 2 calling loadpage... startPage:: newProfile1_1 got a request got a request WEBSHELL- = 1 WEBSHELL- = 0 WEBSHELL+ = 1 WEBSHELL+ = 2 Win pop-up: MOZILLA caused an invalid page fault in module JS3250.DLL at 0157:609d0537. Registers: EAX=140480d9 CS=0157 EIP=609d0537 EFLGS=00010282 EBX=000000d0 SS=015f ESP=0063f5e0 EBP=0063f5ec ECX=0000001a DS=015f ESI=0063f840 FS=5837 EDX=0063f8d0 ES=015f EDI=00000000 GS=0000 Bytes at CS:EIP: 88 18 0f b6 99 84 b5 9f 60 85 db 7e 1a 6a 00 56 Stack dump: 00a74560 0063f840 0081fb10 0063f6ec 609cdd7d 00a74560 0063f840 0000001a 00a74560 0063f840 0081fb10 0063f8c8 007d3490 0063f654 00000000 609e4d1d

ssu has done the installer work, and i've done the build script work. Should be fixed in today's build, marking fixed.

*** Bug 21392 has been marked as a duplicate of this bug. ***

*** Bug 20752 has been marked as a duplicate of this bug. ***

It still crashes. Is it really fixed? The URL to download the MS Upgrade is for Win98? Where is the thing for NT? Is it just SP6? There are computers that need to Run with earlier version Service Pack (e.g.) Ones running Oracle Application Server 4.0.7. Can this really be fixed to work independetly on the MSVCRT.DLL version - is it really so different. As this was very soon introduced I could suppose IT maybe work arounded without required newer version of Service Packs for NT.

I have the same problem that mozilla's daily builds crash during the installation. I too tried the fix described by the additional comment of cpratt@netscape.com (1999-12-09 13:25) and downloaded the file speu.exe. However I could see no improvement, mozilla still crashes. Also running the install program did not change the c:\windows\msvcirt.dll file.

As luck would have it, the Microsoft installer is doubly broken (I verified this morning on a fresh install of Windows 98) - it doesn't update your .DLLs correctly. So, you actually have to do this: - Go to http://www.microsoft.com/Windows98/downloads/contents/WURecommended/S_WUFeatured /Libraries/Default.asp - Download the Microsoft Libraries Update (SPEU.EXE) - Open a command prompt and navigate to the location of SPEU.EXE . - Type the following without the quotes: "SPEU /t:c:\windows\desktop /c" - (change that as necessary to download to the correct location) - This will extract a bunch of a files. One of them is MSVCRT.DLL . - Find the new MSVCRT.DLL , rename it MSVCRT.NEW and copy it into c:\windows\system . - Reboot into DOS (select Start | Restart in MS-DOS mode). - Change into the c:\windows\system folder. - Type REN MSVCRT.DLL MSVCRT.OLD . - Type REN MSVCRT.NEW MSVCRT.DLL . - Type EXIT . This assumes you're using Windows 98 or Windows 95. Under NT, the procedure is somewhat different. Once you've done all that, you should be able to run Mozilla. If not, delete your Users50 folder and mozillaregistry.dat file and try again. If you still can't, and if you're running a non-English system, try deleting or renaming the Java plug-ins in the \plugins directory (see bug 21305). If you still can't, and if you're crashing in GKGFXWIN.DLL, wait for a fix (see bug 21352). If you still can't launch it... I suppose you get to file a new bug.

I'm going to go ahead and mark this as verified fixed. I have heard plausible reports that this week's versions of the installer do upgrade the msvcrt.dll file correctly and allow one to launch mozilla. Oh- - almost forgot. mdaskalo: yes, the file isn't just for Windows 98. I've verified that it works on NT and 95 as well. I wouldn't use it with Windows 2000 though. (Disclaimer: your experience may vary, etc.) Please reopen the bug if anyone has the old version of msvcrt.dll, runs a post-13-Dec-1999 installer, reboots, and finds the old (5.x) version of msvcrt.dll in their \system directory. thanks!

changing QA contact to gbush

After dogfood and for Beta1, bug 10432 (no re-start required after installation) will necessitate us to revisit this fix (and anything that relies on this fix). thx, kevin

*** Bug 21861 has been marked as a duplicate of this bug. ***

I added a comment in 17788 to release not this for m12.

*** Bug 21009 has been marked as a duplicate of this bug. ***

*** Bug 22362 has been marked as a duplicate of this bug. ***

I ran into this problem yesterday before reading the M12 release notes. I filed bug 22362 which I just marked as a dupe. I have a question though: John Morrison wrote: .....(deleted) However, what it really comes down to is: What version of the MS C runtime dll's do you have? These two files must have these version numbers: msvcrt.dll - 6.0.8168.0 msvcirt.dll - 6.0.8168.0 .....deleted My question is that I have msvcrt.dll - 6.00.8397.0 and msvcirt.dll - 6.00.8168.0 This seems to mean that newer versions also have a problem? Should we really be messing with the Windows System directory? I certainly hope that a better solution to this is found. All a user would have to do to break your fix is to go to Windows Update and get the latest Microsoft Libraries patch as apparently I did.

Hi, this bug cannot be considered fixed. How do I install these libraries on Windows NT? Are these libraries part of the Operating System? or part of C Libraries of the OS? Which OS - NT, 95, 98, 2000? What is they all use different libraries? or part of Microsoft's C Libraries? or part of Mozilla/Seamonkey/Netscape5 ... ? I think that it's not good that a product requires a specific version of the C library. It'll become a mess just like on linux with GLIBC 2.0/2.1 !!! Until build M11 everything was OK. So this must be a newly introduced problem in the code. It really needs to be found and fixed. Regards, Mihail Daskaloff

As the installer actually updates the needed files everything works. But to be able to overcome bug 10432 (no-restart needed) this will need to be tracked down. As a strategy this FIX is not the best solutions but works for now. Happy Holidays to all.

*** Bug 22801 has been marked as a duplicate of this bug. ***

*** Bug 22903 has been marked as a duplicate of this bug. ***

*** Bug 21673 has been marked as a duplicate of this bug. ***

*** Bug 23258 has been marked as a duplicate of this bug. ***

*** Bug 23426 has been marked as a duplicate of this bug. ***

*** Bug 21541 has been marked as a duplicate of this bug. ***

Clearing REMIND. Per Beta QA Status mtg today, we would lik a solution for beta 1 if possible.

Sending over to clayton to check out.

This is silly -- I'll take the bug back. Either it's a JS bug, or an old MS CRT malloc bug, or both. If it's not a JS bug, we'll have to find a workaround. /be

I don't get it. Why is this bug opened again? I thought there was a fix by making the installer install the latest dlls? Surely this isn't reopened because someone said we shouldn't install the latest dlls. I'm sorry, but when there are bugs in dlls out there they are supposed to get replaced. MS does this time and and again. The encourage others to do it as well. When you start using a feature or run into a bug that is in their dlls they expect you to ensure the user has the updated ones. I'm sorry if that sucks, but that's windows.

Roger, this one has been characterized as a problem with the dll. The stock MS dll causes SeaMonkey to crash, but for anyone using MSVC++ or Adobe, installation of their software automatically upgrades the dll. So in engineering we normally don't see the problem. The crash is in JavaScript somewhere and may result from argument mismatch or call to a function not in the stock dll. Wondered if you'd set up a crashing configuration and debug far enough to see if you can find the cause of the crash. If it's truly in JS we can help out. Dan Veditz is probably a good contact for background. This came up at a Seamonkey beta review today. Two resolutions may be possible, ship the updated dll with our releases or fix our code to work on the earlier dll. The former is considered a poor choice because it will make installation of SeaMonkey two step. That is, dll installation will require a reboot before Netscape can be used. We haven't forced customers to do that in the past and would prefer not to do so now. Working on the installed base of dll's is the better choice. Sorry for passing you the "most annotated bug in Netscape history" (well, it's at least a candidate). Please feel free to contact previous owners for advice and help. Thanks, = C =

If you dump the new .dll into the Mozilla directory, do you still need a restart before Mozilla will work? Does Windows use a newer version of the .dll if it is available locally in Mozilla's directory? If so, would this be the solution? I read somewhere than Windows 2000 does not allow installers to upgrade the operating system's set of .dll files, so this might be needed anyway.

Win2k might be a problem for future installs, but for this particular item Win2k is new enough that it won't have the old files that are causing the problem.

My questions about installing .dll in Mozilla directory still stand.

Here's what I tried this morning on my copy of Windows NT (SP 5): - Replaced the version 6.00 msvcrt.dll file in \winnt\system32 with version 4.20.6164 of MSVCRT.DLL (from the Office 97 install files) - Tried to launch seamonkey. Result: crash. - Copied MSVCRT.DLL version 6.00.8397.0 into the main Mozilla directory. Result: crash on launch. - Moved the 6.00.8397.0 MSVCRT.DLL into the \components directory of the Mozilla directory. Result: crash. So... I couldn't get it to work that way. Perhaps it's possible to change something in mozilla.exe to look for a local copy of MSVCRT.DLL first (before looking in \%WINDIR%\SYSTEM32? I'm not a developer so I don't know. Anyone?

Some versions of windows give you a module based on the internal module name, and if it already thinks it's loaded you get the already loaded version even if normally you think you're asking for a different one in a different directory. So normally the search path for DLL's is the executable (current) directory first, if you try to load "MSVCRT.DLL" and a different copy is already loaded then you get that one--and the MSVCRT.DLL in the system directory is guaranteed to be already loaded by the OS. I think you can get around this if you do an explicit LoadLibrary() and use the full pathname, but to do that with the C runtime library is not practical (nothing would link).

Would it be possible to do a FreeLibrary() call to unload the old MSVCRT.DLL and then LoadLibrary() the new one?

No -- the problem is not that *we've* loaded it, the problem is that the OS uses it. FreeLibrary() can only free up our handle to a shared library, but the library itself won't shut down as long as it's in user by anyone. That .DLL is always in use and will always require a restart to replace.

*** Bug 24021 has been marked as a duplicate of this bug. ***

How about statically linking to the library then?

It turns out that MSVC 5.0 installs the 'bad' DLL's, so I've got a build running using that. The debug build runs fine, the optimized build crashes in the prescribed manner (most of the time). I built the optimized build with symbols and have been debugging the crash. Turns out the that n-th (sometimes n=7, sometimes n=9) JSArena in the notePool is getting a trashed 'next' field (as well as others). The values being written into it look like srcNotes : 98 41 d9 80 04 59 98 42 d9 80 04 63. I think these are FUNCDEF's followed by SETLINE's (the line numbers match the location in the file being compiled). I haven't been able to catch someone in the act of smacking these locations just yet. But, Brendan, I was wondering about the code for TOK_FUNCTION in jsemit.c - we close off the code generator at line 599, but add srcNotes for SRC_FUNCDEF a little further down - is this ok? i don't understand the machinery here well enough.

Different code generators (cg2 vs. cg). The SRC_FUNCDEF note goes in the "outer" cg, for the script in which the function-defining statement or expression lives. Smells like a JS bug more and more, but I wasn't able to see it by reading the 11/11 diffs. Roger, can you take read those with an eye on srcnote allocation boundary bugs? Thanks. http://cvs-mirror.mozilla.org/webtools/bonsai/cvsview2.cgi?diff_mode=context&whi tespace_mode=show&subdir=mozilla/js/src&command=DIFF_FRAMESET&file=jsemit.c&rev1 =3.18&rev2=3.19&root=/cvsroot http://cvs-mirror.mozilla.org/webtools/bonsai/cvsview2.cgi?diff_mode=context&whi tespace_mode=show&subdir=mozilla/js/src&command=DIFF_FRAMESET&file=jsemit.h&rev1 =3.6&rev2=3.7&root=/cvsroot /be

Fixes checked into jsarena.h rev 3.6 and jsarena.c 3.5 (also nsprpub/lib/ds plarena.h 3.3 and plarena.c 3.4). Turns out this was a 1995-era bug in NSPR 1.0 arenas (which makes it my fault) that became exposed only last fall, and in a very subtle way: JS uses arena MARK and RELEASE, but until the advent of a separate arena-pool for JS source notes, it never allocated a contiguous pair of arenas to the same pool, *after* marking the end of the full-allocated, lower-addressed one; and then released the mark and wrongly set the upper arena's avail cursor to point at the arena header(!). Kudos to rogerl for outstanding debugging and analysis. No DLL upgrade needed, yay! /be

No DLL upgrade means no restart needed! That's absolutely fantastic news. Thanks a bunch. Huge, huge product win. I bow before thee, kevin

After fixing the bug did you remember to take out the dlls as they are not needed?

First test on WIn95 looks good, no crashing, installed and then replaced the installed msvcrt.dll and msvcirt.dll with copies of the older version (5.00.7022) Seamonkey launched and went through minimal sanity check will test on Win98 and WinNT before verifying

Using the 2000011908 Mozilla build on Windows NT 4.0 with MSVCRT.DLL version 4.20.6164, I don't see any problems running the application. I'll leave it to gbush to mark it verified fixed, however.

used builds 2000011913 for testing on all Win machines (95,98,NT,2000) used MSVCRT.DLL and MSVCIRT.DLL (versions 5.00.7022) launching multiple times with no crashes (see bug 24373) tracking removal of these .DLLs from installers so reboot is not necessary

bug 33386 sounds kinds suspicious to me. Could this problem be back?