Closed Bug 19165 Opened 25 years ago Closed 25 years ago

[DOGFOOD][PP] Win32 - App won't start with old MSVCRT.DLL

Categories

(SeaMonkey :: Installer, defect, P1)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: tgrier, Assigned: rogerl)

References

Details

(Whiteboard: [PDT+] Fix available, need build team help)

Attachments

(1 file)

File created by Windiff showing new and changed files after VC++ install/uninstall
18.22 KB, text/plain
Details 
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) :
Assignee: ssu → selmer
Component: Install Wizard → Profile Manager
It crashed in the Profile Manager.  Reassigning to Steve Elmer.
Assignee: selmer → gbush
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.
Summary: Crash installing latest build on Win NT → [DOGFOOD][REGRESSION]Crash installing latest build on Win NT
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?
Summary: [DOGFOOD][REGRESSION]Crash installing latest build on Win NT → Crash installing latest build on Win NT
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. ***
Assignee: gbush → mccabe
Component: Profile Manager → Javascript Engine
Target Milestone: M12
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.
Summary: Crash installing latest build on Win NT → [DOGFOOD] Crash installing latest build on Win NT
adding myself to cc: since this is happening to me all the time with new
profiles, existing profiles.
Summary: [DOGFOOD] Crash installing latest build on Win NT → [DOGFOOD] Crash starting application on Win NT
*** 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..
Whiteboard: [PDT+]
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
Assignee: mccabe → brendan
Reassigning to Brendan, as he seems to be handling it.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
*** 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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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.
Status: REOPENED → ASSIGNED
Assigning, need to reproduce under a debugger, if not under purify.
Summary: [DOGFOOD] Crash starting application on Win NT → [DOGFOOD] Crash starting application on Win NT/98
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. ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
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.
Resolution: WORKSFORME → ---
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.
Assignee: brendan → ckritzer
Status: REOPENED → NEW
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.
Assignee: ckritzer → brendan
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
Status: NEW → ASSIGNED
Priority: P3 → P1
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.
QA Contact: gbush → rginda
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!
Summary: [DOGFOOD] Crash starting application on Win NT/98 → [DOGFOOD][PP] Win32 - App won't start with old MSVCRT.DLL
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.
Assignee: brendan → ssu
Status: ASSIGNED → NEW
Component: Javascript Engine → Installer
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
Status: NEW → ASSIGNED
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.
Whiteboard: [PDT+] → [PDT+] Fix available, need build team help
*** 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!
Assignee: ssu → leaf
Status: ASSIGNED → NEW
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
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
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.
Blocks: 21564
Blocks: 10432
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.
Status: RESOLVED → VERIFIED
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!
QA Contact: rginda → gbush
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.
Status: VERIFIED → REOPENED
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
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: FIXED → REMIND
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. ***
Status: RESOLVED → REOPENED
Target Milestone: M12 → M14
Resolution: REMIND → ---
Clearing REMIND.  Per Beta QA Status mtg today, we would lik a solution for beta
1 if possible.
Assignee: leaf → clayton
Status: REOPENED → NEW
Sending over to clayton to check out.
Assignee: clayton → brendan
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.
Assignee: brendan → rogerl
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
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
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?
Blocks: 24373
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.
Status: RESOLVED → VERIFIED
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
Blocks: 24854
Target Milestone: M14 → M13
bug 33386 sounds kinds suspicious to me.  Could this problem be back?
No longer blocks: 21564
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: