If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

memory use in installer is *very* high

VERIFIED FIXED in mozilla0.8

Status

SeaMonkey
Installer
P4
normal
VERIFIED FIXED
17 years ago
13 years ago

People

(Reporter: Henrik Gemal, Assigned: Sean Su)

Tracking

Trunk
mozilla0.8
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [xpibug])

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
The win32 installer seems to be using a lot of memory just to display the setup 
options.
If you just start the installer the mozilla-win32-installer.exe uses 14.972 K on 
my Win2000 machine, which seems like a lot compared to other installers.

Anything that can be done?
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: P3 → P4
If we're using 14Mb before even launching XPCOM we could be in trouble. There 
are tons of 4K buffers everywhere which could be easily chopped way down.

Not committing to fix, but perhaps worth looking at so throwing into the 
nsbeta1 pile for a more detailed look.
Keywords: nsbeta1
(Reporter)

Comment 2

17 years ago
Just starting todays installer (mozilla-win32-installer.exe) 20010103 so that 
the installer stands at the Welcome screen, shows up as 16.148 KB Memory usage 
in Windows 2000 Task Manager.
Whiteboard: [xpibug]
Moz 0.8 tasks
Target Milestone: --- → mozilla0.8
(Assignee)

Comment 4

17 years ago
I'm not sure how you're getting the 14.972K and 16.148K under NT2k.

Under NT2000's task manager, I get 2.124K (build 01/15/01) and 1.828K (build
01/30/01) for SETUP.exe

Under NT4's task manager, I get 2.536K (build 01/15/01) and 2.300K (build
01/30/01) for SETUP.exe

All memory figures were determined at the Welcome screen.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Reporter)

Comment 5

17 years ago
Ok here's the deal. I'm not talking about the setup.exe. I'm talking about the 
mozilla-win32-installer.exe

Starting mozilla-win32-installer.exe shows me 16.148 KB

BUT if I first do "-u" and the launch setup.exe it shows me 2.124K
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Reporter)

Comment 6

17 years ago
Created attachment 23922 [details]
screenshot of installer and task manager

Comment 7

17 years ago
We're past time to cut these low priority bugs from mozilla0.8.  Please update
these bugs today. 
(Assignee)

Comment 8

17 years ago
I found the problem.  There are two things happening:
1) memory leak in nsinstall.cpp itself (which can easily be fixed)
2) memory usage (not leak) from a windows specific api that we cannot release,
but that the api itself releases just prior to the app exiting (thus not a
memory leak).

Essentially, I can bring down the memory usage down to as low as 7-8mb for now.

Patch coming up.
(Assignee)

Comment 9

17 years ago
Created attachment 24453 [details] [diff] [review]
patch #1
r=dveditz

This patch fixes the leak but not the windows-specific lame resource handling. 
They put explicit calls to free specific kinds of resources (bitmaps, cursors, 
etc.) so they recognized the problem, but nothing for a generic user-defined 
resource such as we're using.
I suppose one option might be to have nsinstall launch setup.exe and then not 
wait for it to finish up. We'd have a cleanup problem though, which could be 
partially addressed by passing flags and/or paths into setup.exe when it was 
supposed to do the cleanup. But we wouldn't be able to get rid of setup.exe 
itself
(Assignee)

Comment 12

17 years ago
I'd rather not leave setup.exe laying around.  Another alternative is to use
infoseek's code for self-extracting .exes.  This path would also enable the
installer to be built under Win9x as well as NT.  But this is a different bug.

seeking sr= now.
Status: REOPENED → ASSIGNED

Comment 13

17 years ago
sr=mscott
(Assignee)

Comment 14

17 years ago
patch checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 15

17 years ago
The memory usage after starting mozilla-win32-installer.exe is now down to:
10.708 KB

That's:
8.560 KB for mozilla-win32-installer.exe
2.148 KB for setup.exe

Much better...

BTW: Why does mozilla-win32-installer.exe still need to live as a process when 
setup.exe is lauched????
Status: RESOLVED → VERIFIED
(Assignee)

Comment 16

17 years ago
it needs to wait for setup.exe to exit in order to clean up 2 things:
1) TEMP\ns_temp\xpcom.ns - because xpcom does not unload all dlls it loads; ref
counting is messed up.  Since setup.exe is the main app, when it exits, all dlls
loaded by it will be unloaded.
2) TEMP\ns_temp\setup.exe - because it can't delete itself while it's still running.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.