22005 - On Win9x install "freezes" during install of many files

Status: VERIFIED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect, P1)

Description

[Jimmy Lee]

Build: 1999-12-14-09-M12

1. Install 1999-12-14-09-M12
2. Launch and go to current build for windows,
   ftp://sweetlou/products/client/seamonkey/windows/32bit/x86
3. Open update.html
4. Leave only Navigator checkboxed
5. Click Launch XPInstall button

RESULT:
Installation appears to occur.  After some time, the Downloading dialog appears
with "Finishing install...please wait".  Eventually, the spinning progress
dialog will stop.  This process is "frozen".  Clicking on other places
on the desktop returns no action.  Bring up the task list and selecting
Cancel curiously appears to restore the spinning of the progress dialog.  But
I'm not confident that the installation resumes.  The Install.log always is
incomplete failing writing out to anywhere from 200's, 300's, etc.  It seems
that it may vary from one installation attempt to another.

EXPECTED RESULT:
Installation completes gracefully with no system locking up.

NOTE:
I tried to install this same core.xpi from http://jimbob/jars using my own
trigger at http://jimbob/trigger2.html, and the same problem occurs.  Therefore,
it appears that there is likely no problem with update.html.

Note that other xpis can be installed such as mailnews and aim with no freezing.
Installation succeeds on Windows NT.

Comment 1

[Daniel Veditz [:dveditz]]

The core installation has by far the largest number of files. This appears to
be a resource issue.  When I tried it my Win98 machine locked up good for a
while, but the UI came back to life after a while.  The install never
progressed past a fairly early stage of finalization.

This would be worth trying on a wimpy (memory poor) Mac as well.  I'll give
this a run through leaky and see if there's something obvious.

Comment 2

[Jimmy Lee]

Build 1999-12-20-12-M12

Reproduced on Windows 95, 500MHz, 128MB RAM

System locks up, and reboot is necessary.

Comment 3

[Daniel Veditz [:dveditz]]

I can reproduce this on Win9x, thanks. Has it been tried on a wimpy Mac?

Comment 4

[Jimmy Lee]

My Macintosh 8500 with 64 MB was able to update.  I did have to copy the xpis to
my local drive to succeed.  There appears to be some problem with http.

Comment 5

[Samir Gehani]

It's worth it to note that the update of browser.xpi took Jimmy 23 min 54 sec
based on his install log.

Comment 6

[Jim Race]

Jimmy and Dan, are you getting a lot of disk thrashing while this is happening
or do things simply appear to hang? I guess at the same time can I ask to get a
"zippy" to try for M13 when you're ready? Plus whatever tweaks I might need for
my local config files. My main test platform at home is win98, PIII 733, 256M
and loads of disk.

Comment 7

[Jim Race]

Upon thinking, a few more questions. Redundant, maybe.
1) Win98SE or first release?
2) What OS version on the Mac?
3) Have you tried this on NT, running task manager?, or better yet;
4) Have you tried it under Win9x running WinTop?  (Number of threads spwaned
would be interesting)

Anyway. Perhaps I should trundle off to bed. Anyway, I'm back and interested.

Comment 8

[Daniel Veditz [:dveditz]]

Good news, this can be reproduced using http://jimbob/jars/manyfiles.jar which
means the test doesn't blow away the mozilla you're testing requiring a
reinstall before doing another test.

The problem is running out of 16-bit USER resources, which appear to be used up
when DOM elements are changed on the dialog. During the bulk of the script
(unpacking the files) the USER resources drop, but during the final
phase (when we attempt to update the progress bar) they go into free-fall.

If I comment out the dialog updates during that final phase the USER resource
usage goes up to ~90% in the first phase but all or most of the resources are
recovered when the install is done, so they can't quite be considered "leaked"
but it's hard to imagine code that would keep those handles around to clean
them up later.  Maybe they're owned by JS objects and GC is triggered later,
but not soon enough to keep mozilla from hanging the system in the full test.

This is not something that can be fixed in XPInstall code, and not something
that will realistically get done in M13. Pushing out to M14.

This may presage serious problems for DHTML apps on Win9x when those apps do a
lot of content twiddling.  In fact, we should try to narrow a test case even
farther and get XPInstall totally out of the bug.

Comment 9

[Daniel Veditz [:dveditz]]

Doug's patch attached to 23969 fixes this one too.

Comment 10

[Daniel Veditz [:dveditz]]

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

Comment 11

[Doug Turner (:dougt)]

wtc checked in our fix to both the m13 branch and the trunk.  Marking as fixed.

Comment 12

[Jimmy Lee]

I was able to get this to work on Windows 95.  I'm still locking up on Windows 
98 in AIM, so I'm still looking into it.

Comment 13

[Doug Turner (:dougt)]

try using the mozilla build, 

Comment 14

[Daniel Veditz [:dveditz]]

Jimmy, it's not clear what you mean by your problem with AIM. Do you go to the 
update page and install *only* AIM, or are you installing a lot of stuff and 
AIM happens to be where it stops?

What about the manyfiles.jar? That one definitely exhibited the problem so you 
should test that on both Win95 and Win98 if you suspect further problems.

Comment 15

[Jimmy Lee]

I install whatever is the default from the update.html page, so I install a 
bunch of stuff before the AIM package.  I'll try installing without AIM.  And 
I'll try manyfiles.jar as well (good idea!).

Comment 16

[Daniel Veditz [:dveditz]]

An of course you should install *just* AIM on the crashing machine to determine 
if there is something with that particular install or if it's a multi-install 
issue.

Comment 17

[Jim Race]

Guys, If you want me to I'll test this on my Win98SE box (256M). It's pretty 
clean as I use it often from home for Blue Martini QA. You can either make the 
jars public or drop them to me in email here. I have the bandwidth. -- Jim Race

Comment 18

[Jimmy Lee]

Build: 2000-02-02-15-M14 (WIN)

It turns out that I can do the update successfully.  I let my Win 98 finalize 
all night long, and it does eventually complete.  Apparently, I was simply not 
letting finalize complete.

Comment 19

[Daniel Veditz [:dveditz]]

Yeah, half the time with the original problem I could leave it a couple of 
hours and it would work. Having to wait overnight is obviously not "fixed". The 
question is, is it a *different* problem.

We still need details on: 1) does AIM update alone cause the problem, or just 
as part of multi-trigger, 2) does manyfiles.jar have a problem

Comment 20

[Doug Turner (:dougt)]

reopening.

Comment 21

[Doug Turner (:dougt)]

assiging back to dveditz.

Comment 22

[Jimmy Lee]

1. AIM does update alone
2. manyfiles.jar does update fine
3. It appears that it simply takes a long time to install because if I uncheck
   AIM from the update.html page, then MAIL takes a long time or appears to do
   so
4. And what I had suspected was a factor appears to be a significant factor if
   not the only reason for the long installation.  If I start with a new   
   nsreg.dat, then installation is pretty quick.  It took about 3.5 minutes    
   according to the Install.log to install Browser, SSL/HTTP, Mail, and Instant    
   Messanger.

Comment 23

[Laura Yecies]

pdt - is this an edge case or does this happen on typical install?

Comment 24

[Daniel Veditz [:dveditz]]

This was found running the standard mozilla XPInstall package, that is, 
*exactly* what users would be trying to do.

Comment 25

[Jimmy Lee]

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

Comment 26

[Daniel Veditz [:dveditz]]

dooming doug

Comment 27

[Doug Turner (:dougt)]

related to 19114?

Comment 28

[Daniel Veditz [:dveditz]]

That bug seemed to indicate GDI leakage. On the original bug I was seeing USER 
resource leakage. Also, if you didn't run out we got it back, and in 19114 they 
didn't get much back at the end.

If you run a resource viewer now (after the previous fix for this bug) what do 
you see running out?

Comment 29

[Doug Turner (:dougt)]

spoke with eric.  this sould like a dup.

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

Comment 30

[Daniel Veditz [:dveditz]]

Reopening so I can re-close as fixed so it will correctly be reflected in the 
bug stats. 22005 originally was about some eventQ stuff and Doug did actually 
fix it. Then the bug was morphed into another problem that turned out to be a 
dup, but the original problem was fixed.

Comment 31

[Daniel Veditz [:dveditz]]

Original bug fixed. Morphed bug (19114) also fixed

Comment 32

[Jimmy Lee]

Build: 2000-02-07-09-M14(WIN) to 2000-02-09-19-M14(WIN)

I can update.  Performance is another issue.

Comment 33

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/00a1ad166a26
[fenix] For https://github.com/mozilla-mobile/fenix/issues/22005 - Ensure deleted items are removed from the list