Closed Bug 361852 Opened 18 years ago Closed 17 years ago

Seamonkey virtual memory use continually increases

Categories

(SeaMonkey :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: q1, Unassigned)

References

Details

(Keywords: memory-leak)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061101 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061101 Firefox/1.5 I use Seamonkey for a variety of general browsing, including plain HTML pages, pages with Flash, and pages with PDFs. I do not shut down the system on which Seamonkey is installed, but rather put it in standby when I'm done working each day. Under this usage, Seamonkey's virtual memory use continually increases, and does not significantly decrease even if I close all but one window (right now, it's this one). Closing a window containing a simple HTML doc reduces use by ~100KB. Closing a window containing a PDF doc reduces use by ~2-3MB. After 4-5 days of ordinary use, VM use reaches 350-400MB. Also possibly related is that after 4-5 days, the thread with the following stack continuously uses ~5% of the CPU: ntkrnlpa.exe!KiUnexpectedInterrupt+0xf0 win32k.sys+0x2fa0 win32k.sys+0x1b80 win32k.sys!EngFreeUserMem+0x3d38 ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14 ntdll.dll!KiFastSystemCallRet ntkrnlpa.exe!KiDispatchInterrupt+0x5a2 NDIS.SYS!NdisFreeToBlockPool+0x15e1 ntdll.dll!KiFastSystemCallRet pnen3260.dll!DdeCallback+0xada pnen3260.dll!DdeCallback+0x6249 pnen3260.dll!DdeCallback+0xb89 PNCRT.dll!beginthreadex+0xe5 kernel32.dll!GetModuleFileNameA+0x1b4 I have experienced similar problems with Mozilla ever since I began using it with ~V1.7. Before Seamonkey 1.1b, the browser also got significantly slower as its memory use increased. Someone fixed something, because 1.1b does not seem to exhibit this behavior. A good page to illustrate the problem quickly is http://finance.yahoo.com/q/cq?s=ibm,gm,t,ge,msft,aapl,intc,cy,lu,nt,f,tm,csco , which (during times when the stock markets are open) shows continuously-updating stock quotes. My only extension is Adblock v5 d3 nightly 42. The problem occurs even if I disable Adblock. I am also using the Flash 9.0 r16 plugin and the Acrobat reader 7.00 plugin. Reproducible: Always Steps to Reproduce: As above. Actual Results: Almost monotonically-increasing memory usage that becomes grossly excessive after 3-4 days of use, and that cannot significantly be reduced by closing tabs and/or windows. Expected Results: Reasonable memory use that declines appropriately when I close tabs and/or windows.
Oh yes, I disabled the forward/backward cache by setting browser.sessionhistory.max_viewers / browser.sessionhistory.max_total_viewers to 0.
Seamonkey 1.1 release version exhibits the same behavior.
Keywords: mlk
As does SeaMonkey 1.1.1. I too run my system for long periods at a time and the memory just keeps growing until my computer gets so slow I need to close SM and restart it. This usually happens when the Windows Task Manager reports SM at 300 MB of memory usage, but it does get pretty slow from anywhere beyond 150. I did notice that resolving bug 336973 helped slow down the memory leak though.
I can confirm this. My system (Windows XP) is usually running for weeks or even months and I have a lot of browser windows open. And I also have partially very large mail folders. SeaMonkey is getting much slower the more memory it consumes, this was not a such big problem with the old Mozilla Suite (1.7.12). Right now seamonkey.exe consumes 907.023 K for just 20 browser and 2 mail windows. Does seamonkey actually free memory at any time? It seems that it always just allocates new memory. But I don't want to restart my browser each day, because then I'm losing much work and have to open a lot of windows again.
To q1@lastland.net(bug opener), Jaisen, Marten Lehmann : Please clearly describe at least which you are talking about - "Memory Usage" column or "Virtual Memory Size" column of MS Windows's Task Manager if you talk about memory related problem you encountered on MS Win. And please understand at least difference of "Memory Usage" column and "Virtual Memory Size" column of MS Win before opening/commenting to bug saying "too large memory usage". And read thru Bug 320915 first, then read Bug 378077, Bug 376476 and so on, please. Same asking as Bug 320915 Comment #28, and same questions as Bug 320915 Comment #42. By the way, please don't misunderstand that I say no memory leak on Tb. I'm opener of Bug 329876.
Do you see *brower-only* memory problems using a) trunk build[1] and b) flash block extension installed? [1]Trunk is getting significant memory management improvements. So trunk tests are more useful than branch test FWIW, many of the bugs mentioned in Wada's comment 5 and bug Bug 329876 comment 11 have patches on trunk or are getting significant attention, eg. Bug 379070, and Bug 388353
The continued increase of memory is a typical sign of "memory fragmentation"[1]. This was recently addressed on trunk in the efforts to reduce Firefox memory usage, see <http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/>. SeaMonkey still contains some additional known memory leaks but those are covered by other bugs. While I have experienced things like mentioned in previous comments, too, I think the issue of this bug is much too hazy to be addressed by developers, so we can as well close it. ----- [1] This term refers to the problem that even if SeaMonkey frees memory, it often cannot be used by the system because there are bits of memory on both sides of that block that are still used by SeaMonkey.
As said before, this bug has lost direction a while ago. If you think you still see a concrete memory leak on a certain page, please follow the instructions on <http://wiki.mozilla.org/QA:Home_Page:Firefox_3.0_TestPlan:Leaks:LeakTesting-How-To> to verify that you found a real leak and open a new bug with that information.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.