254281 - mozilla.exe does not cleanly shutdown; prevents later launch

Status: RESOLVED EXPIRED

(SeaMonkey :: General, defect)

Description

[Gary Lowther]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707

Frequently (though not 100% of the time), when the window manager is used to
exit Mozilla (i.e. click on the "X" box in the upper righthand corner), although
the GUI disappears, the "mozilla.exe" process remains in memory. Since this is
*not* the requested behavior (i.e. the quick launch feature is *not* in use), it
is unexpected.

The true downside is that this defunct process blocks all future launches of
Mozilla. Any attempts to launch a new browser window result in a new
"mozilla.exe" process that does *not* show the GUI, or do much of anything
except consume memory (only about 3-4 MB). If the defunct "mozilla.exe" process
is killed, these new "mozilla.exe" processes will instantly resume from their
suspension and proceed with a normal launch.  This manual kill of the
didn't-go-away process is *always* required to correct the situation.

Initially, I thought this must just be something weird in my environment.
However, after asking a few of my colleagues, I learned that I am not the only
one who has seen this behavior. It could still be a shared/common environmental
thing, but I now believe it is worth reporting.

Reproducible: Sometimes
Steps to Reproduce:
1. Launch Mozilla (make sure quick launch is disabled; if not, disable it, then
start over).
2. Do a little work... surf around... whatever.
3. Close the browser using the window manager, meaning click on the "X" in the
upper righthand corner of the title bar of the window. Do not use the "File" menu.
Actual Results:  
Check the Task Manager and see if a "mozilla.exe" process is still present in
memory. If it is, that's the bug (remember that the quick launch feature is
disabled). If you try to open up Mozilla again, it will *not* open, although a
new, very small, "mozilla.exe" process will show up in the Task Manager.

Expected Results:  
No "mozilla.exe" process should remain in memory (check via the Task Manager;
again, make sure that the quick launch feature is disabled). Launching a new
Mozilla browser instance should be successful.

Comment 1

[Patrick]

Does the problem persist if you try with a clean profile? [start the profile
manager].

Comment 2

[Gary Lowther]

Hi Patrick. I created a new profile, and had no difficulty recreating the
problem with it. I'm assuming that's as "clean" as I can make it. Let me know if
I should have tried something else!

I should also add to my original comments that I *am* seeing this problem via
the "File"->"Exit" approach, too, not just via the window manager shutdown.
Which makes sense! I just hadn't had time to explicitly test it out.

Comment 3

[Gérard Talbot]

Please check for DUPLICATE too when filing a bug. Right now, there are 70
bugfiles (unconfirmed, new, assigned or reopened) which have the "shut" and the
"down" words/strings. I would be quite surprised if there was not an already
opened bugfile meeting this bugfile description.

For starters, bug 241114 description is exactly like this bugfile's description.

Comment 4

[Gérard Talbot]

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

Comment 5

[Gérard Talbot]

"be sure that you've reproduced your bug using a build released within the past
three days. Our development process moves at lightning speed, and the bug you've
found may already have been fixed."
http://www.mozilla.org/quality/bug-writing-guidelines.html

Gary, is the problem/behavior still reproducible in a recent trunk build?

It is my understanding that using the close button or Alt+F4 under the system
menu or File/Exit Ctrl+Q should be mapped the same way; at least, it ought to be
the same under Windows.

I could use some help to figure out what would be the duplicate for this bug:
http://www.mozilla.org/quality/help/screening-duplicates.html
http://www.mozilla.org/quality/help/beginning-duplicate-finding.html

Comment 6

[Gary Lowther]

I just installed 1.7.2, which was released today, and was able to recreate the
problem immediately.

As for duplicates, for the record, I *did* perform a duplicate search, on
"Browser" and "1.7 Branch". Apparently, the latter selection torpedoed my
chances of actually finding anything. ~sigh~ In performing yet another duplicate
search, I've found a large number of bugs that reference the inability of
Mozilla to cleanly shutdown when the entire OS is being shut down (on Windows
only). Frankly, I'm not sure if those are relevant to mine or not. Certainly the
one you found, 241114, is absolutely identical, but I see that you've duped that
one to mine for some reason (instead of the other way around).

Since I work for IBM and they actually expect me to work on *their* products
(the unreasonable fiends!), I'll have to continue my search for a good duplicate
candidate later! If I find a match, I'll dupe this bug to it right away. 
However, just so you know that I'm not completely copping out on you, take a
look at 236540 and 236768. I think the latter is a good candidate. I run several
Java-based applications on my workstation (as do the other engineers who are
also seeing this problem). We are a huge Eclipse shop!

Comment 7

[Gérard Talbot]

Ok, Gary, then verify the JRE version you're using and try to use 1.4.2_05
downloadable from 
http://plugindoc.mozdev.org/windows.html#Java

You may want to read bug 229281. One thing I'm sure of is that JRE is still
active, loaded in memory even after one may no longer be using an applet. Also,
the problem of closing application *and* unloading from windows memory
management could be related to other stuff: recently loaded activeX or plugins
(music, radio, acrobat reader, etc..) (see bug 65462 on this) associated with
the Mozilla application you ran before closing it.

Hint to confirm/pinpoint possible source/cause of bug: 
Start/Settings/Control Panel/Java Plug-in/Basic tab/Show Java in system tray
(restart computer to save changes)
and then try again to reproduce the behavior when Java is NOT shown in system
tray or verify/confirm that there is a Java icon in the system tray when Mozilla
process/application refuses to be disposed, unloaded from windows memory
management. Or does the problem happens when you do NOT have the Java icon shown
in system tray?

Rigth now, there are strong chances that I will resolve this bug, bug 229281 and
bug 236540 as DUPLICATEs of bug 236768.

Comment 8

[Gary Lowther]

Per the recommedations, I upgrade my Java plug-in to 1.4.2_05 (including the
requested reboot) and enabled the Java console debugger. After the reboot, I was
no longer able to recreate the defect, which is not all that surprising. What is
more surprising is that after quite a few days now, I *still* have not been able
to recreate the problem. Hardly conclusive evidence that the newer level of Java
resolves the problem, but an interesting data point anyway. Probably should dupe
this bug to 236768.

Comment 9

[Patrick]

reporter do you mind if we mark this as Worksforme then?

Comment 10

[Gary Lowther]

Well, since you mentioned it...  I should report that after weeks of not seeing
this problem at all (ever since I upgraded Java), I am now seeing it again.
That's the bad news.  The good news is that I have a 100% consistent way to
reproduce it on my system.

I'm a programmer, and my editor of choice is Visual SlickEdit.  SlickEdit
provides a "Web" button on it's toolbar which should launch a browser (also a
"Support" option under the "Help" menu). When I click on this button, no browser
appears, SlickEdit hangs (and has to be forcibly killed), and from that point on
I have the problem with Mozilla mentioned in this bug report. I have no idea
exactly what launch mechanism SlickEdit is using to bring up a browser, but I
would *assume* that it is simply performing a standard system 

I don't know if that is helpful at all, but I just wanted to get it reported. I
have the Java console enabled (as suggested by [e-mail]), and it
doesn't report any activity. I know it's working properly though, because every
time I am forced to launch Internet Explorer, it popups up and shows some Java
exceptions related to a buggy plug-in for IE.

I am now running Mozilla 1.7.2, but *not* the latest daily build. I'm also still
on Windows 2000 Pro, fully patched.

Comment 11

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 12

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.