Closed Bug 190816 Opened 22 years ago Closed 22 years ago

Running process causes Installer to hang until process is shut down via task manager

Categories

(SeaMonkey :: Installer, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.4alpha

People

(Reporter: agracebush, Assigned: ssu0262)

References

()

Details

(Whiteboard: [adt1])

Attachments

(5 files, 8 obsolete files)

Steps to reproduce: 1. Run application - download new build (2003012508) 2. Leave application running with QuickLaunch enabled 3. Run Installer Actual results: Installer gives warning that application needs to be closed- but does not remove process(viewed in task manager)- installation completes- launches but does not allow use of profile (it is being used by older process) expected results: Installer closes running processes before installing files
Sean, I am not sure if this is new behavior- since on other platform I can run multiple processes with different profiles. Since switching profiles has been checked in- this may be 'as designed'
QA Contact: bugzilla → gbush
hmmm... it's suppose to close everything that it finds. sounds like a regression with quitting quick launch. I'll investigate when I get the chance.
Assignee: dveditz → ssu
It does close down QuickLaunch (removes systray icon anyway) and closes open browser windows- but process remains. sometimes it hangs at this point- if you delete process, it continues successfully while other times it continues and launches second process.
ah, this might be a bug with the browser itself, as opposed to the installer. I have seen the browser not shutting down by itself. I too had to kill the process by hand from time to time. Try shutting the browser down by hand before starting the installer at all. Check the Task list to make sure it has quit. I'll bet that it doesn't always fully quit by itself.
fyi: I've actually see this happening before my GRE patch landed
a few more observations with todays build to test what happens when browser is exited 1. close browser (QuickLaunch process running) 2. run installer reach point of GRE Install- see greinstaller in task mgr also see a second netscp process (very small 3608k vs 18000+k of first one), nssetup.exe, SETUP.exe and SETUP.exe (not sure which goes with GRE/or installer itself). Also now see xpicleanup running. 3. choose to not reboot 4. Warning that app needs to be shut down is NOT given but....all processes mentioned in step 2 disappear. 5. while watching task manager- installation starts up and launches so something in background DOES shut things down
Keywords: nsbeta1
changing summary: steps to recreate Enable QuickLaunch File/Exit browser Run Installer Installer completes GRE install Systray icon disappears, but checking task manager shows netscp.exe process running Installer is hanging (can see nssetup.exe in task manager) shut down netscp and Installer proceeds.
Summary: Installer not detecting running process → Running process causes Installer to hang until process is shut down via task manager
Installer triage team: nsbeta1+/adt1
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt1]
Attached file test cases to reproduce this bug (deleted) —
Sean, Added test cases here- see #1 and #3, occurs when browser left open - doesn't seem related to QuickLaunch.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.4alpha
*** Bug 196049 has been marked as a duplicate of this bug. ***
*** Bug 197407 has been marked as a duplicate of this bug. ***
Attached patch patch v1.0 (moz tree) (obsolete) (deleted) — Splinter Review
this will (hopefully) fix a couple of things: * no longer show the reboot dialog at the end of the install process * fully shutdown the browser so installer can continue.
the ns patch is attached to bugscape bug: http://bugscape.mcom.com/show_bug.cgi?id=23271
Sean, This is not happening today- Installer is closing down the app windows (both open and closed) as well as QuickLaunch.
duh, still leaves the running process. But it does not continue install until I kill that process-- before it was continuing on with the install despite process running
this is good to know. I was talking to alecf, and he suggested to try to kill the process itself if the first attempt to shutdown the browser fails. I'm going to try to implement this.
Attachment #119360 - Attachment is obsolete: true
Attached patch patch v1.1 (obsolete) (deleted) — Splinter Review
I've tested this patch under Win2k. This should work the same way under Win9x systems and WinXP. However, NT4 will use a different (very confusing) code. I don't have NT4 with me, so I'll have to test it when I find an NT4 system. Here's what it will do: * If Mozilla is found running, it'll call it with -kill to quit its QuickLaunch (running or not). * Check if Mozilla is still running (via a FindWindow() call), if so inform the user to quit Mozilla or else it'll for it for them. This first time, will be a "nice" quit, where it will send a WM_CLOSE message to all of the windows. This will now *timeout* after 3 secs in case Mozilla is non responsive (it didn't used to timeout before). * After user clicks OK, it'll check again to see if Mozilla is still running, this time by looking for it's process name in the OS process list. If Mozilla is still found to be running, it'll inform to user to try to quit it via the Task Manager, or it will do it for them. This time, it will be a 'hard' quit where the process will be terminated if it likes it or not. The function I'm calling to do this here is TerminateProcess(), which does not have a timeout value. It might hang here, but I'm not sure. * If Mozilla is still found to be running, setup will attempt to do a 'hard' quit on it until MAX_KILL_PROCESS_RETRIES has been reached (set to 7 right now). * If this max is reached, then setup will inform the user to try manually killing the process indicated and rerun setup again. Setup now quits.
Attached patch patch v1.2 (obsolete) (deleted) — Splinter Review
upgraded patch from v1.1 that now shows a message while waiting for the browser to shutdown, which can be potentially long.
Attachment #120163 - Attachment is obsolete: true
Attached patch patch v1.3 (obsolete) (deleted) — Splinter Review
Attachment #120208 - Attachment is obsolete: true
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030411 After 2003-04-11-08-test190816/mozilla-win32-installer.exe, I tried to open it from Download Manager, to no avail. So I started it in a Windows Explorer window, Mozilla still running. I didn´t want to install into the directory of my default Mozilla Iinstallation, so I specified a new one: C:/Programs/Mozilla.org/190816 It was created, and download started, and I could go on surfing for about half an hour, while downloading the files ( ISDN, theoretically 8kb/s, practically up to 7.5 kb/s). When download finished, I got an acoustic signal, so I looked at that process. I was asked to quit the browser, or let the program do it, and I allowed the programm to kill my beloved Mozilla. I was asked two times more, with a slightly different wording, and I confirmed. In the end, Mozilla with some windows and a lot of tabs had been killed on demand, but no installation started, taskmanager didn´t show either Mozilla nor setup running. Writing of my bookmarkfile needs about 8 seconds, see bug 201562. Maybe this was irritating installer.exe, asking two times more that mozilla was still running, and should it try again to kill it. So I started installer.exe again, was told it didn´t finish an installation, and was asked if it should reuse the downloaded files, that would save download time. I agreed, and installation went on. Installation was fine, but had a small error: It didn´t take the directory specified, created and used in the first try, but deinstalled my default directory, and installed there. P.S. I didn´t have quickstart running or selected.
I've updated this bug with the url to the test build. I'll update it again on newer test builds. Hermann, thanks for finding and trying out the test build. Do you remember if on the 3rd time you saw the message informing you that you had to somehow quit the browser yourself because it was having diffuculties doing so for you? And that it was going to quit setup as well? Here's the exact wording that I'm wondering if you saw: Setup is having diffuculties quitting Mozilla (Mozilla.exe). Setup cannot continue unless this process has quit. Please try manually quitting the process, then run Setup again. If you did see this, then the patch to this bug is doing what it should. Your writing of your bookmark file needing about 8 seconds (bug 201562) is probably causing the browser to not fully shutdown before the timeout was triggered. I'll increase the timeout value from 3secs to 10secs and see how it feels to wait a little longer before timing out. I'll also change the patch to not return before the timeout value expires if the OS thinks the process is hung. I've noticed that the OS has been wrong in more than one occassion. > It didn´t take the directory specified, created and used in the first > try,but deinstalled my default directory, and installed there. Did you change the destination directory when you re-ran the installer? The installer doesn't save the previous destination patch chosen. Also it doesn't deinstall before installing ontop of a previous build (this is called an upgrade), but it does try to clean up obsolete files as much as possible. If you had no problems with Mozilla starting up at the end of the install, and that you were _not_ prompted for a reboot at the end of the install as well, then the patch seems like it's doing what it's suppose to be doing. I'll get an updated patch attached and request another test build from release eng. I'll update the url once the test build is delivered (probably won't happen till Monday now).
I think I saw that message, but I didn´t notice that mozilla was running. IIRC the visible part of mozilla got killed instantly after my first response, and after this third response I didn´t see anything. So I pressed Ctrl-Alt-Delete and looked at the processe, nothing to be seen related to mozilla. I didn´t specify the path when I started again, assumed since it noticed it has been disturbed it would go on were it was halted. But I know I have to look at paths and profiles each time I made a change. regarding daily installs: nearly a year ago I switched to zip-installs which were better at that time and didn´t require a deinstall. After I noticed that flash doesn´t work perfectly with zip-installs because it needs some entries in the windows registry, I went back to installer-sea.exe. After I read about upgrade install, I looked into some logs and it seemed that upgrade is a legal alternative to deinstall+reinstall. Is it still necessary to deinstall to be sure ? Last time I´ve got troubles with installation the solution was to switch to zip, because deinstall didn´t solve the problem, or was the root cause, I don´t remember. Is there any advantage of the net installer? I use browser and mail, sometimes venkman, composer. Regarding the size of the package, I doesn´t matter if I save the bytes for chatzilla, or not. Advantage of sea.exe is, that I´ve got only 1 file to archive so I can reinstall it later to look for regressions.
> I didn´t specify the path when I started again, assumed since it noticed > it has been disturbed it would go on were it was halted. yeah, that's a different bug. I've seen it filed, but can't remember the number right now. > ...Is it still necessary to deinstall to be sure ? > Last time I´ve got troubles with installation the solution was to switch > to zip, because deinstall didn´t solve the problem, or was the root cause, I > don´t remember. It's not normally necessary to unisntall prior to installing a new build. I think most (if not close to all) the bugs filed about problems when "upgrading" were due to mozilla not shutting down properly and the installer just continuing, or hanging as in this bug. The uninstallation process pretty much guaranteed that mozilla was not running so it would always work. If installing ontop of a previous build doesn't work after this patch is landed, it would be an "upgrade" issue where obsolete files are being left around and causing problems. I've been pretty deligent about being ontop of obsolete files these days. > Is there any advantage of the net installer? > I use browser and mail, sometimes venkman, composer. > Regarding the size of the package, I doesn´t matter if I save the bytes > for chatzilla, or not. Advantage of sea.exe is, that I´ve got only 1 file > to archive so I can reinstall it later to look for regressions. The advantage is that if you're only needing to install a small subset of the product, this type of installer will not download anything you don't need, thus saving you considerable download time. If you archive the nightly builds, then it's best to download the full, blob installer that contains everything.
Attached patch patch v1.4 (obsolete) (deleted) — Splinter Review
Attachment #120260 - Attachment is obsolete: true
updating the URL to reference new test build with patch v1.4.
Had this built installed from SEA.exe before reading this bug, Build ID 2003041416, Quickstart not enabled, no extensions installed. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030414 then installed from URL above: 1. download of 219 kb installer to a folder 2. after download finished, I started it with Windows Explorer 3. specified to install to the folder of the mozilla I was using. 4. while installing, I went on surfing, for about 2 minutes (DSL) 5. I had to look in the Windows taskbar to find the icon that the installer had finished, maybe, because I switched tabs while surfing. 6. resized status gave only a box with the text 'DOW' and a single button 'OK' 7. I clicked ok, next box came up, and told me it was shutting down mozilla. It shut down mozilla, and an Alert box came up, asking me to shut down manually and then click OK or just click OK . 8. I considered my decision, looked at taskmanager, didn´t see a mozilla, aborted taskmanager and clicked ok. 9. Installation was proceeding normally, even to the folder I was using, didn´t have to specify. Conclusion: point 6. didn´t raise my attention, and the text was mutilated, because the Message Box wasn´t big enough. point 7. after confirming DOW, shutdown was automatic, iirc without calling me, and Alert Box came up instantly that Mozilla was still running. There should be a loop of up to ten seconds testing, before giving alert, or continue testing, while alerting. Rest was ok. Should I retest with quicklaunch enabled?
Mozilla to replace: BuildID 2003041404 1. download of installer 2. Installer started with Windows Explorer 3. Surfing while downloading ( 30 min Win98-DUN/ISDN ) 4. at the end of download the title of the downloadbox in the tray changed to ATTENTION. This doesn´t alert a user, it´s visible only if one look at it. Resizing the box gives a square box about an inch sized, containing the title 'Attention' and a greyed out x, an Alert sign, the text 'DOW' and a button 'OK' 5. When I clicked 'OK', Mozilla was immediately shutdown, and a small box titled 'Mozilla Setup' told me: Shutting Down Mozilla. Please wait. 6. While waiting nearly a minute, I sent a half-sized explorer window to the tray, and closed it there. The mozilla Setup Window didn´t repaint, but I´m scarce on resources on this computer. Then it was replaced by a box: Mozilla has detected to be still running ... or something like that. 7. Ctrl-Alt-Del showed me a hanging Mozilla, I killed it, and then Setup went on as usual. Difference between this and the previous installation: Time for waiting that mozilla has closed. This installation was downloading from DUN, and was immediately shutting down after confirming text DOW, but was the waiting for 30 seconds or more, to verify that mozilla has closed, and then told me it is still running. Celeron 333, DUN, 96 MB RAM and a slow pagefile. Previous installation was from a DSL-Router/Switch, which is the heart of a small 4-computer network ( Win95 + Win98SE ). After the download from net finished, I confirmed text DOW and it was immediately shutting down the browser, but also immediately the next box came up telling me that mozilla is still running.
Thanks for testing the build. It sounds like it's doing what it is suppose to be doing, with the exception of the initial weird message box size. This initial message box is informing that the browser needs to be shutdown. I'll have to run the build on a win98 system to see if it's reproduceable. What language is your win98 system? Also, in 6), the reason why it doesn't repaint is because the installer is not multithreaded and that it's waiting for a call to SendMessageTimeout() to return. The reason is took so long is because mozilla can take a very long time to shutdown on slow systems. You can try it with quicklaunch enabled, but I doubt it would make a difference because you ran into the 'Mozilla hanging on shutdown' problem already.
both systems german language, mozilla english language, 800x600 screen LAN, Win98SE, AMD XP1600+, 2x256MB RAM on nForce integr. graphics (MSI K7N420pro) ISDN, Win98 SP1, Celeron 333, 32+64MB RAM, 8 MB Sis6328 noname graphics card
If you get a chance, could you get a snap shot of the messed up dialog(s) that you're seeing?
*** Bug 193064 has been marked as a duplicate of this bug. ***
Attached image Alertbox at end of download (obsolete) (deleted) —
had to download again to get this box, but messing around with saving the screenshot did make the setup-message unreadable. Screenshot shows first box. With Ctrl-Alt-Del (Win98) I saw two instances of mozilla marked hanging, I killed one, and setup went on, till now.
Attached patch patch v1.5 (obsolete) (deleted) — Splinter Review
This updated patch: * adds a 1 sec delay after ending a process before checking to see if it's still running. * fixes the string display problem found by Hermann.
Attachment #120344 - Attachment is obsolete: true
Attachment #120769 - Flags: review?(dveditz)
new trunk test build with patch v1.5 (url updated)
BuildID 2003041713 contains bug 202439, a crasher, regressed on windows starting with 2003041709. After download and start of Installer installation went normal, when download finished I got a system sound. In the tray was only a small window, which had only place to show 'Att..'. I clicked on it, but it didn´t open. I had to close a lot of windows and minimize the browser, to get it into the foreground. Once I had it in the foreground, I could minimize and maximize it, all was working. When I hit ok, after about a second delay next box came, telling me Mozilla was still running. Ctrl-Alt-Del was showing me that no mozilla was running, so I confirmed mozilla setup, and setup started automatically. AT some time in the setup there was no window showing setup activity, i.e. between closing of one setup progress window and opening another one there was some seconds delay, 10 or 20, I didn´t watch a watch ;-) Then I did some surfing, wondering why I didn´t hit bug 202439, when I was closing tabs. When I closed the browser and DUN, it crashed, and DocWatson was showing a stack summary like seen at bug 202439. TB19269999Z
Attached patch patch v1.6 (obsolete) (deleted) — Splinter Review
okay, this patch will now show the warning dialog in front of all dialogs.
Attachment #120769 - Attachment is obsolete: true
Attachment #120769 - Flags: review?(dveditz)
Attachment #120988 - Flags: review?(sgehani)
Attached patch patch v1.7 (deleted) — Splinter Review
Attachment #120988 - Attachment is obsolete: true
Attachment #120988 - Flags: review?(sgehani)
Attachment #121352 - Flags: superreview?(dveditz)
Attachment #121352 - Flags: review?(sgehani)
Attachment #121352 - Flags: review?(sgehani) → review+
Would be nice to test this installer with 1.4b, before it goes into 1.4. I assume, users of nightlies are installing from zip or using the full exes, but that is pure speculation.
Flags: blocking1.4b?
Re comment #39. I use the Windows installer (the ~280K download), then use it to download the xpi's and install.
This fix should definitely be a blocker for the next release (1.4b) because it'll prevent lots of potential mozilla startup problems which make it appear like it's caused by something incomprehensible in the browser.
Attachment #121352 - Flags: superreview?(dveditz) → superreview?(jaggernaut)
Flags: blocking1.4b? → blocking1.4b+
Comment on attachment 121352 [details] [diff] [review] patch v1.7 sr=jag
Attachment #121352 - Flags: superreview?(jaggernaut) → superreview+
Comment on attachment 121352 [details] [diff] [review] patch v1.7 This fix prevents lots of potential (win32) mozilla startup problems which make it appear like it's caused by something non-comprehensible in the browser. It'll also fix problems where the user gets the infamous error message that's hard to reproduce: The program must close to allow previous installation attempt to complete. Please restart. It'll fix this because the message will only show when newly installed files were not installed because they were in memory at time of installation (one of those bugs being bug 197164). The risk of this patch is moderate. It's not high because we most of the code was already there and working (like the actual killing of the process). The new code deals with how to "keep trying" to kill the process in question and inform the user of what it's doing (and quitting setup if it still can't after several tries). Test builds have been built by release eng, and been have tested by an external tester who keeps seeing the reboot dialog at the end of install (a good indication that other problems might arise) and by gbush@netscape.com.
Attachment #121352 - Flags: approval1.4b?
Comment on attachment 121352 [details] [diff] [review] patch v1.7 a=sspitzer
Attachment #121352 - Flags: approval1.4b? → approval1.4b+
patch checked in! *whew*
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Attached image 1st alert: Download successful (deleted) —
WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030425 1. download of installer 2. start of installer from Download Manager 3. surfing while waiting endless 200 seconds 4. AlertBox was showing minimized in Windows Taskbar 5. maximized and confirmed alertbox, 6. 2nd AlertBox came up: Setup has detected that Mozilla is still running. 7. After having done a screenshot and filing it, I confirmed. 8. Mozilla was aborted and installation started 9. At end of installation I had to select one of my profiles, ok. 10. Good work! My screensize: 800x600, can also attach 2nd alertbox if needed.
Attachment #120708 - Attachment is obsolete: true
Attached image Installation Display (deleted) —
just repeated installation, to be sure. Had folders ns_temp and ns_temp2 in my windows/temp/ directory, and after successful installation another folder added: ns_temp3. Attached the display of the box while downloading. If you minimize this box, because you want to browse while downloading, you are not alerted at end of download, because the box in a crowded windows taskbar holds only the symbol while downloading, and afterwards the letters Att... Would be nice if this box could pop-up at end of download.
Attached image 2nd Alert: Mozilla still running (deleted) —
for sake of completeness, and can somebody update the URL field, I installed from: http://ftp.mozilla.org/pub/mozilla/nightly/2003-04-25-04-trunk/mozilla-win32-installer.exe
verified on build 2003042504 results same as with test build had to rerun setup after process killed or kill in task manager per instructions in which case setup finished on its own. one nit- alert says to manually close Mozilla in commercial build- despite reference to netscp.exe process - will open another bug for that
Status: RESOLVED → VERIFIED
*** Bug 204540 has been marked as a duplicate of this bug. ***
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: