146530 - Shutdown crash [@ AddNullTerminator]

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[Jaime Rodriguez, Jr.]

Build ID: Gecko/20020523 Netscape/7.0b1 
Reproducible: Frequently

Steps:
1. Download the Stub Installer
2. Double click the Stub Installer, with QuickLaunch running
3. Run a Custom Install, make selections as desired, then click NEXT to all screens
4. Get error message, that Netscape must be shut down before installing. Click OK

Results: Recieved an XPCOM: Event Reciever: Netscape.ex - Application Error ...
The instruction at "0x61172c21" referenced memory at "0x6117e878". The memory
could not be written error, upon install with QuickLaunch ON for a single
profile. Resulted in a crash in addition to Error.

Comment 1

[Jaime Rodriguez, Jr.]

This is [ADT1 RTM] as it will significantly impact most user's installing on
WinXP, with 128MB of memory.

This might be resolved by http://bugscape.mcom.com/show_bug.cgi?id=15904

Comment 2

[Jaime Rodriguez, Jr.]

Talkback Incident:
http://climate.netscape.com/reports/incidenttemplate.cfm?bbid=6604130

Comment 3

[Daniel Veditz [:dveditz]]

Did any of the install happen? It's not clear to me if you mean the currently
running old version crashed or if the install continued and then crashed as it
was launching the newly installed browser.

Why do you think this is related to bugscape 15904? The stack traces look
completely different. This one's crashing in strings doing something with the
command line.

Comment 4

[Jaime Rodriguez, Jr.]

Answers to Dan's Questions:

Q1) Did any of the install happen? 
A1) Yes, after the two error dialogue you receive: 1) From MachV when
QuickLaunch is running, and you kick off an install, and the 2) The XPCOM error,
looks likes its from the WindowsXP OS.  You can continue the install by clicking
OK to both dialogues. [Note: At this point the user has already double-clicked
on the stub installer, and some files have been downloaded].

Q2) It's not clear to me if you mean the currently running old version crashed
or if the install continued and then crashed as it was launching the newly
installed browser.
A2) To be clear, it appeared to ME, as though, "the currently running old
version crashed" as the installer attempted to *shutdown*. Hence, the reference
to http://bugscape.mcom.com/show_bug.cgi?id=15904 (Crashes on shutdown [@
Xprt.dll]), which manifests itself when the user tries to manually shutdown
Netscape from the SysTray.

Q3) Why do you think this is related to bugscape 15904? The stack traces look
completely different. This one's crashing in strings doing something with the
command line.
A3) See A2 above for how I came to this assumption. I have been able to
frequently reproduce both crashes, and they appeared to occur, when shutting
down the application, either manually, or when killing the app as part of an
install.

Did this help?

Comment 5

[Henrik Gemal]

is this a mozilla or netscape bug?

Comment 6

[Joseph Elwell]

Doesn't look like any Netscape specific code:

 Call Stack:     (Signature = AddNullTerminator 9f2fe034)
     AddNullTerminator [d:\builds\seamonkey\mozilla\string\obsolete\nsStr.h,
line 340]
     nsStrPrivate::EnsureCapacity
[d:\builds\seamonkey\mozilla\string\obsolete\nsStr.cpp, line 126]
     nsStrPrivate::GrowCapacity
[d:\builds\seamonkey\mozilla\string\obsolete\nsStr.cpp, line 151]
     nsCString::SetCapacity
[d:\builds\seamonkey\mozilla\string\obsolete\nsString.cpp, line 181]
     nsString::SetLength
[d:\builds\seamonkey\mozilla\string\obsolete\nsString2.cpp, line 178]
     nsACString::UncheckedAppendFromReadable
[d:\builds\seamonkey\mozilla\string\src\nsAString.cpp, line 885]
     nsACString::do_AppendFromElement
[d:\builds\seamonkey\mozilla\string\src\nsAString.cpp, line 904]
     nsNativeAppSupportWin::GetCmdLineArgs
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsNativeAppSupportWin.cpp, line 1709]
     nsNativeAppSupportWin::HandleRequest
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsNativeAppSupportWin.cpp, line 1533]
     MessageWindow::WindowProc
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsNativeAppSupportWin.cpp, line 834]
     USER32.dll + 0x3a5f (0x77d43a5f)  
     USER32.dll + 0x3b2e (0x77d43b2e)  
     USER32.dll + 0x5874 (0x77d45874)  
     USER32.dll + 0xbab6 (0x77d4bab6)  
     ntdll.dll + 0x108f (0x77f5108f)  
     USER32.dll + 0x3fb0 (0x77d43fb0)  
     ole32.dll + 0x36d7e (0x771e6d7e)  
     ole32.dll + 0x36ce0 (0x771e6ce0)  
     ole32.dll + 0x17ed9 (0x771c7ed9)  
     ole32.dll + 0x174dc (0x771c74dc)  
     ole32.dll + 0x174a8 (0x771c74a8)  
     ole32.dll + 0x45192 (0x771f5192)  
     _CRT_INIT@12()  
     _DllMainCRTStartup@12()  
     ntdll.dll + 0x2e3aa (0x77f7e3aa)  
     ntdll.dll + 0x1b1c6 (0x77f6b1c6)  
     kernel32.dll + 0x15c84 (0x77e75c84)  
     kernel32.dll + 0x15cc7 (0x77e75cc7)  
     msvcrt.dll + 0x279c8 (0x77c379c8)  
     kernel32.dll + 0x1eb69 (0x77e7eb69) 

Comment 7

[Daniel Veditz [:dveditz]]

This bug is particular to the nightly you were running at the time. As long as
people in the field don't have the buggy version we can move on.

Test cases:
 - run <old version>
 - leave window open, start install of new version
 - click button to close old version when prompted, shouldn't crash.

Where <old version> is 6.1, 6.2.x and 7.0b1 (and 6.0 if you have time, but I
don't think we worry as much about that). The 6.2 can be any of that series.

Comment 8

[Jaime Rodriguez, Jr.]

Ok ... However, I do not beleive it to be "particular to the nightly you were
running at the time", because this was also seen by Scott Davison (Web
Properties), during launch day testing for Netscape 7.0 PR1.  

Comment 9

[Daniel Veditz [:dveditz]]

multiple stack traces

Comment 10

[Daniel Veditz [:dveditz]]

Crashing in strings, installer is not doing anything in particular here. Strings
might not be the problem either, we're probably trying to do something with an
object that's already been released.

Comment 11

[jag (Peter Annema)]

This isn't strings.

Comment 12

[Samir Gehani]

-> law for a look

Comment 13

[Bill Law]

Probably what is happening is that the installer is launching another instance
of the executable while the first one is still in the process of shutting down.
 There is a known problem (sorry, I don't know the bug # off-hand) where this
will crash if the second instance sends a request to the shutting-down instance
within a particular window of time.

A simple fix might be to add code that notes that we're shutting down and checks
that state before accepting incoming IPC requests.  The shutdown happens when we
travel certain paths through nsNativeAppSupportWin::OnLastWindowClosing, or, in
the code that handles the "Exit Mozilla" QuickLaunch systray menu item.  All
incoming requests come through nsNativeAppSupportWin::HandleRequest.

Note that this is similar to the code that we recently added to block such
requests when we're restarting in QuickLaunch mode.

My suggested fix would basically add a PRBool static data member to
nsNativeAppSupportWin.  Let's call it "mShuttingDown."  Add code to
OnLastWindowClosing to set that data member to PR_TRUE in the case where we know
we're going to be terminating after the last window closes.  Add similar code to
the place where we detect the selection of "Exit Mozilla."

Then add code (or embellish the current code that checks for !mInitWindow) in
HandleRequest so that it ignores requests if mShuttingDown is PR_TRUE.

I'll try that myself, when I get time.  Or, somebody else could give it a go.

I *think* we could test by running the patched version while installing an
unpatched version (meaning that we can test this without having to build an
installer version with the patch).

Comment 14

[Daniel Veditz [:dveditz]]

I don't think all the black boxes were doing an install. Another way to reproduce
(sometimes) is to shutdown windows. Sometimes that leads to the Xprt.dll crash
instead though.

the installer does not launch Mozilla immediately after shutting it down. It
does initialize a stripped-down XPCOM, but in a temp installation that doesn't
have any of the browser startup/shutdown/attach-to-another-process code in it.

Comment 15

[Samir Gehani]

Nav triage team: nsbeta1+, adt3 rtm

Comment 16

[Samir Gehani]

Nav triage team: nsbeta1-