The Memory Leak Problem Still Exists in Mozilla 1. 6 alpha on Win98



16 years ago
15 years ago


(Reporter: asilver76, Unassigned)


Windows 98

Firefox Tracking Flags

(Not tracked)





16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031030

The memory leak/graphics corruption problem that was so prevalent in versions
prior to 1.6 still exists in the 1.6 alpha. although the problem takes much
longer to manifest itself - up to a number of hours. However, prior to
manifesting, the system shows the same symptoms as prior versions - overall
slowdown, problems with windows switching, and decreased command responsiveness.
When the graphical corruption occurrs, it takes the same form as previous
problems of the same nature - i.e. screen refeshes do not occur, and content is
merely overwritten. Resizing the window causes the window to refresh. This
problem also seem to hang versions of sun java (1.4.1-1.4.2) in memory, not
allowing the java compinent to unload, and causing the mozilla application to
stop responding when triggered to shut down. Bottom Line: whatever workaround or
patch was used to fix this problem - be it a change in used memory footprint,
new cache flushing code, or whatnot - the implementation is still incomplete,
and while this problem is no longer a showstopper, its presence indicates that
future versions of Mozilla could break this "fix/workaround", as happened in the
Mozilla 1.5 RC3. There should be no reason, at this point, for the core broswer
component to have any sort of cache/memory/buffer overflow, given the maturity
of the codebase. It is strongly suggested that the full-time Mozilla developers
devote a period of a week or so to fully soulve this problem, lest it come back
to haunt future versions, especially once the full mozilla firebird core swap
gets gets up to speed.

Reproducible: Always

Steps to Reproduce:
1.Use the 1.6 alpha browser for an extended period, preferrably on
graphics-heavy pages.
2.Open up as many graphics/pages/images in individual windows (not tabs) as
3.Keep browsing and observe results, the time it takes for said results to
manifest, and the system resources reported utilized at the time.

Actual Results:  
The same as reported above. No special steps are needs to attain this result;
the above details step merely causes the effectis to manifest in a shorter
period of time.

Expected Results:  
Render any and all pages correctly, refreshing content completely when
applicable, for as long as the application is in use. 

The system used is a PIII 550, w/8MB NVIDIA Vanta chipset, and 128 MB RAM
OS: Windows 98SE
No addtional backgorund processes running. 
Mozilla is not set for quicklaunch.
The only plugins used are flash and sun java 1.4.2. 

Additional requested specifics will br provided upon request.

Comment 1

16 years ago

*** This bug has been marked as a duplicate of 204374 ***
Closed: 16 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.