Bug 21181

Summary: Netscape 4.76 memory leak
Product: [Retired] Red Hat Linux Reporter: Michael Schwendt <bugs.michael>
Component: netscapeAssignee: Bill Nottingham <notting>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: medium    
Version: 7.0CC: dr, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-11-24 05:29:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michael Schwendt 2000-11-21 14:56:09 UTC
Big fat warning to everyone around:

*** DO NOT use the 4.76 update! ***

One of its undocumented features is a real ugly _memory leak_ which quickly
eats up all virtual memory (128 MB RAM and 256 MB swap-space on my
machine). Compared with real heavy use of 4.75, it is obvious that 4.76 is
the cause of this memory consumption.

The first time this happened, I was fast enough to kill it fortunately. It
occured when I lauched Netscape Navigator for the first time to bypass the
licence agreement at the beginning. I then quit Navigator and started
Communicator immediately and suddenly heard unusual HD swapping noise. 'ps
uxw' revealed that Navigator's processes were still busy doing something,
apparently. The second time it happened shortly after startup of Navigator,
while loading a few simple news pages at Yahoo!. Unfortunately, I was not
fast enough to protect the system from locking.

Comment 1 Bill Nottingham 2000-11-21 15:55:33 UTC
Are you using java at all?

Comment 2 Michael Schwendt 2000-11-23 12:52:36 UTC
No Java at all. That means no JDK installed on this machine and Java disabled in
browser. Just JavaScript is enabled.

Since this bug might depend on glibc <= 2.1.94-3, I've decided to test-drive
4.76 with the new glibc 2.2.

Comment 3 Bill Nottingham 2000-11-24 05:29:25 UTC
Just checking ; the JVM has been notably leaky in the past.

Comment 4 Michael Schwendt 2000-11-24 23:14:52 UTC
Just like the problems with xmms and sendmail, I think this bug is caused by
problems with the glibc pre-release snapshots. Well,  either that or really some
strange addition in Netscape 4.76.

I'm successfully running Netscape 4.76 with glibc 2.2 for quite some time by
now.

But when I downgraded to glibc 2.1.94-3 just for fun ;-), it didn't take a
quarter of an hour to get that memory leak lock-up again (I was replacing
hardware components and had to reboot several times -- this was the best
opportunity to load Netscape from scratch which takes longer than when it loads
from disk cache).

Note that I'm certain it has to do with the startup/shutdown procedure in
Netscape 4.76. It has nothing to do with loading specific pages or running the
browser for a long time. Also, it is  not just an ordinary memory leak which
slowly takes away chunks of memory, but -- provided that it occurs -- a real
critical one which eats up the entire virtual memory in less than half a minute.

Conclusively, as long as this misbehaviour does not happen with the glibc 2.2
update, I consider this as fixed.

Comment 5 Andrea Sterbini 2001-02-12 15:06:17 UTC
I am using netscape-communicator-4.76-1 on Redhat 7 with glibc-2.2-12 and kde
2.0.1 ... 
Netscape freezes often and I am always ready to do a killall -9
netscape-communicator.
It seems this happens when Javascript is active, or when I use email ...
Perhaps there is some lock coming out from network delays?


Comment 6 Michael Schwendt 2001-02-12 16:16:03 UTC
> Netscape freezes often and I am always ready
> to do a killall -9 netscape-communicator.

Netscape usually just _seems_ to freeze. Wait 2-3 minutes and watch how it comes
back to life. I don't know what it does meanwhile. Maybe its related to
time-outs or close-to-deadlock like code choking on pages or DNS lookups. Try
Galeon or Mozilla >= 0.7 as an alternative.

(And to not start any confusion -- afterall, this bug has been closed since the
glibc update -- I haven't had that memory leak since then.)