Closed Bug 571392 Opened 16 years ago Closed 15 years ago

memory leak found with Mac OS X leaks program

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: schneidt, Unassigned)

Details

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4 I have a severe memory leak on my Mac OS X 10.6.3 and while trying to hunt it down I found the command 'leaks' which can be run in a mac Terminal. This program reveals leaks in Seamonkey. Reproducible: Always Steps to Reproduce: 1. Start Seamonkey 2. In a Mac OS X Terminal type: leaks seamonkey 3. stand back and then observe the first few lines Actual Results: egg:~] toms% leaks seamonkey Found process 19278 (seamonkey-bin) from partial name seamonkey Found process 19278 (seamonkey-bin) from partial name seamonkey Process 19278: 509564 nodes malloced for 50022 KB Process 19278: 3929 leaks for 186832 total leaked bytes. Leak: 0x14485e00 size=8192 zone: DefaultMallocZone_0x140a000 0x00000000 0x03ff2000 0x87fffffe 0x07fffffe ..... .......... 0x00000000 0x00000000 0xffffffff 0xffffffff ................ 0xffffffff 0xffffffff 0xffffffff 0xffffffff ................ 0xffffffff 0xffffffff 0xffffffff 0xffffffff ................ 0xffffffff 0xffffffff 0xffffffff 0xffffffff ................ 0xffffffff 0xffffffff 0xffffffff 0xffffffff ................ 0xffffffff 0xffffffff 0xffffffff 0xffffffff ................ 0xffffffff 0xffffffff 0xffffffff 0xffffffff ................ ... Leak: 0x212dc00 size=2560 zone: DefaultMallocZone_0x140a000 string ' ' ... [many lines deleted] Leak: 0x1d2f9340 size=16 zone: DefaultMallocZone_0x140a000 0x1d2f8880 0x018391cc 0x14ec3c00 0x00000001 ../......<...... Leak: 0x1d2fa010 size=16 zone: DefaultMallocZone_0x140a000 0x1d2fa110 0x018391cc 0x14eae410 0x00000000 ../............. [egg:~] toms% Expected Results: The Terminal program itself dose not give leaks and serves as a control: [egg:~] toms% leaks Terminal Process 165: 32096 nodes malloced for 7668 KB Process 165: 0 leaks for 0 total leaked bytes. [egg:~] toms% The amount of leaks increases with usage of Seamonkey. I don't know if this is the main cause of my problem though. However, the problem is able to eat up 2 GB of memory eventually. Activity Monitor does not show anything in particular, but the Free memory drops and Inactive increases. This can be seen from the command line with the top command too. When the machine runs out of memory, everything freezes and I have to reboot. Stopping Seamonkey releases some memory but does not restore everything. This still happens in safe mode, started with: try safe mode: cd /Applications/SeaMonkey.app/Contents/MacOS/ ./seamonkey-bin -safe-mode
[egg:~] toms% man leaks leaks(1) BSD General Commands Manual leaks(1) NAME leaks -- Search a process's memory for unreferenced malloc buffers ... "The leaks reported will always be true leaks."
On my Mac at home, also 10.6.3 Mac Pro fully upgraded, I had a Seamonkey running for quite a while. This was the report: leaks seamonkey | head Found process 67533 (seamonkey-bin) from partial name seamonkey Found process 67533 (seamonkey-bin) from partial name seamonkey Process 67533: 4950964 nodes malloced for 389314 KB Process 67533: 121895 leaks for 4403072 total leaked bytes. Leak: 0x8df61400 size=2048 zone: DefaultMallocZone_0x140a000 0x00000000 0x00000000 0x00000014 0xc000ff9c ................ 0x00000000 0x00df7a80 0x00d8ac1e 0x00000000 .....z.......... 0x00000000 0x00000000 0x00000000 0x00000000 ................ 0x00000000 0x00000000 0x00000000 0x00000000 ................ 0x00000000 0x00000000 0x00000000 0x00000000 ................ 0x00000000 0x00000000 0x00000000 0xc000ff9c ................ 0x00000000 0x00e5c7e6 0x00d8ac1e 0x00000000 ................ The machine had little Free memory but I had closed ALL windows. I quit and restarted and now I have 1.74 GB free. So Seamonkey was holding at least 1 GB of memory. However, this machine doesn't crash.
On my Mac at home, also 10.6.3 Mac Pro fully upgraded, I had a Seamonkey running for quite a while. This was the report: leaks seamonkey | head Found process 67533 (seamonkey-bin) from partial name seamonkey Found process 67533 (seamonkey-bin) from partial name seamonkey Process 67533: 4950964 nodes malloced for 389314 KB Process 67533: 121895 leaks for 4403072 total leaked bytes. Leak: 0x8df61400 size=2048 zone: DefaultMallocZone_0x140a000 0x00000000 0x00000000 0x00000014 0xc000ff9c ................ 0x00000000 0x00df7a80 0x00d8ac1e 0x00000000 .....z.......... 0x00000000 0x00000000 0x00000000 0x00000000 ................ 0x00000000 0x00000000 0x00000000 0x00000000 ................ 0x00000000 0x00000000 0x00000000 0x00000000 ................ 0x00000000 0x00000000 0x00000000 0xc000ff9c ................ 0x00000000 0x00e5c7e6 0x00d8ac1e 0x00000000 ................ The machine had little Free memory but I had closed ALL windows. I quit and restarted and now I have 1.74 GB free. So Seamonkey was holding at least 1 GB of memory. However, this machine doesn't crash.
(In reply to comment #2) > On my Mac at home, also 10.6.3 Mac Pro fully upgraded, I had a Seamonkey > running > for quite a while. This was the report: > > The machine had little Free memory but I had closed ALL windows. > I quit and restarted and now I have 1.74 GB free. So Seamonkey was holding > at least 1 GB of memory. However, this machine doesn't crash. FYI, I've seen bugs from windows with that much ram where view image context popup's leak, firebug leaks if you download a large file with it open, spellchecker leaks, netwerk I think was leaking too. Don't know if Seamonkey has some of these leaks in there builds still. If the memory is freed afterward these uses, it maybe one of them.
Severity: major → critical
Priority: -- → P1
I'm increasing the priority on this to P1 Critical. I just logged in a few minutes ago and within 30 minutes all memory was gone and I was forced to reboot to avoid a crash. This is a very serious bug. There should be no leaks whatsoever.
Please read: https://wiki.mozilla.org/Performance:Leak_Tools And install a mozilla specific leak detector: https://wiki.mozilla.org/MozillaQualityAssurance:Home_Page:Firefox_3.0_TestPlan:Leaks:LeakTesting-How-To#Using_Leak_Gauge These pages mention Firefox but the information applies equally to SeaMonkey.
Severity: critical → normal
Priority: P1 → --
(In reply to comment #6) Thanks for looking at this! I set that up and am getting the leak log and am able to analyze it. The Mac OS X leaks program still finds leaks: Found process 13416 (seamonkey-bin) from partial name seamonkey Found process 13416 (seamonkey-bin) from partial name seamonkey ----- head -3 /tmp/toms.leakwatch Process 13416: 239542 nodes malloced for 23709 KB Process 13416: 727 leaks for 35104 total leaked bytes. Leak: 0x18de400 size=1024 zone: DefaultMallocZone_0x140a000 Results of processing log nspr2.log : Summary: Leaked 0 out of 0 DOM Windows Leaked 0 out of 36 documents Leaked 0 out of 8 docshells Leaked content nodes in 0 out of 64 documents So they aren't consistent. The one thing is that the claim for OS X is "The leaks reported will always be true leaks." I don't know what else to do except to wait until I have a severe leak situation and then capture the data again - unless you have other suggestions.
You're using quite an old version of Gecko :( If you use a build with symbols and run it with MallocStackLogging=1, you should be able to get stacks out of |leaks|. I'm still not inclined to believe its results, though, since it relies on pointer analysis and might not know about sneaky things Firefox does. I'm more inclined to trust TraceMalloc or Valgrind, which show the objects that aren't freed by the time the app exits. leak-gauge only shows leaks that involve specific objects: windows, documents, and docshells. Most large leaks involve at least one of these objects, but it's not guaranteed. Also, leak-gauge only shows leaks that last all the way through shutdown; a "leak until halfway through shutdown" can be just as bad for your experience. Unfortunately, none of these tools are great for determining which leaks are actually hurting you. If you have a trunk build, you can try about:memory. (It works in Firefox, at least; I'm not sure about SeaMonkey)
trace-refcnt is my favorite of the tools, fwiw, in part because it's the most fine-grained of the tools for which we consistently show 0 leaks when nothing is going out-of-the-ordinarily wrong. But you'll need a special build to use it.
Tom, The latest trunk builds (2.1a2pre Mac DMGs can be found here. Make sure you use a separate profile when testing with these: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/ Jesse says: > "leaks program always reports stuff as leaked" is kinda known. "seamonkey uses > so much memory for me that i have to reboot" is a separate issue. > > If i run firefox with MallocStackLogging=1 and then run "leaks firefox", i get > some stacks. > > I think it's making invalid assumptions about what is "reachable", though. > > TraceMalloc and Valgrind don't make such assumptions so i'd be more inclined > to believe them. > > For "seamonkey uses so much memory for me that i have to reboot" you probably > want SUMO (does seamonkey use SUMO?) > > For "leaks program always reports stuff as leaked" you want to show bz or > dbaron some output, ask if they agree with me about it being bogus, and > tryTraceMalloc/Valgrind > > Oh also have the reporter try about:memory in a trunk build ;)
Jesse Ruderman said on 2010-06-16 01:31:49 PDT: > You're using quite an old version of Gecko :( Jesse our release branch is still on 1.9.1. We are skipping 1.9.2 and going directly to 1.9.3 for SeaMonkey.next.
(In reply to comment #10) > > Jesse says: > > > "leaks program always reports stuff as leaked" is kinda known. "seamonkey uses > > so much memory for me that i have to reboot" is a separate issue. > > > > If i run firefox with MallocStackLogging=1 and then run "leaks firefox", i get > > some stacks. > > > > I think it's making invalid assumptions about what is "reachable", though. > > > > TraceMalloc and Valgrind don't make such assumptions so i'd be more inclined > > to believe them. > > > > For "seamonkey uses so much memory for me that i have to reboot" you probably > > want SUMO (does seamonkey use SUMO?) > > > > For "leaks program always reports stuff as leaked" you want to show bz or > > dbaron some output, ask if they agree with me about it being bogus, and > > tryTraceMalloc/Valgrind > > > > Oh also have the reporter try about:memory in a trunk build ;) I set up and am using seamonkey-2.1a2pre.en-US.mac.dmg I don't know how to do the other things. The nspr.log is not being created even though I have the environmental variables. about:memory gives: --- Memory Usage Overview Memory mapped: 62,230,528 Memory in use: 33,695,216 Other Information Description Value malloc/allocated33,706,832malloc/mapped62,230,528malloc/zone0/committed33,718,560malloc/zone0/allocated55,939,072images/chrome/used/raw0images/chrome/used/uncompressed264,756images/chrome/unused/raw0images/chrome/unused/uncompressed0images/content/used/raw0images/content/used/uncompressed2,895,672images/content/unused/raw0images/content/unused/uncompressed2,048storage/sqlite814,888layout/all1,314,433layout/bidi0gfx/surface/image3,215,088 --- I don't know what to do next.
62MB doesn't sound terrible. Can you look at about:memory once it's grown to use 1GB? Or is there a serious discrepancy between about:memory and Activity Monitor?
(In reply to comment #13) > 62MB doesn't sound terrible. Can you look at about:memory once it's grown to > use 1GB? Or is there a serious discrepancy between about:memory and Activity > Monitor? Memory Usage Overview Memory mapped: 49,913,856 Memory in use: 20,043,760 Other Information Description Value malloc/allocated20,046,592malloc/mapped49,913,856malloc/zone0/committed20,073,792malloc/zone0/allocated45,719,552images/chrome/used/raw0images/chrome/used/uncompressed256,556images/chrome/unused/raw0images/chrome/unused/uncompressed0images/content/used/raw0images/content/used/uncompressed130,400images/content/unused/raw0images/content/unused/uncompressed1,024storage/sqlite662,040layout/all321,188layout/bidi0gfx/surface/image401,828 activity monitor has: free: 62.5 MB Wired 144.6 MB Active 1.23 GB Inactive 577.4 MB Used 1.93 GB I have seamonkey Terminal and Skim running. Skim showed no leaks with: % leaks Skim Process 312: 52587 nodes malloced for 7992 KB Process 312: 0 leaks for 0 total leaked bytes. Terminal also shows no leaks that way. Seamonkey shows lots of leaks: Found process 10135 (seamonkey-bin) from partial name seamonkey Found process 10135 (seamonkey-bin) from partial name seamonkey Process 10135: 327336 nodes malloced for 31504 KB Process 10135: 1089 leaks for 71552 total leaked bytes. (etc) I'm close to crashing ...
> activity monitor has: > free: 62.5 MB > Wired 144.6 MB > Active 1.23 GB > Inactive 577.4 MB > Used 1.93 GB That's your overall RAM usage, from all apps together, and maybe also the filesystem cache. You don't really have to worry about "running out" because you can always swap less-frequently-used pages to disk. You want the memory-use columns next to your browser's process in the list, such as "Real Memory" and "Real Private Memory". Why do you think you're close to crashing?
(In reply to comment #15) > That's your overall RAM usage, from all apps together, and maybe also the > filesystem cache. You don't really have to worry about "running out" because > you can always swap less-frequently-used pages to disk. One would think ... see below. > You want the memory-use columns next to your browser's process in the list, > such as "Real Memory" and "Real Private Memory". I have all those displayed but they didn't seem excessive. I rebooted so can't check right now (and have 1.01 GB free). > Why do you think you're close to crashing? The pie circle which displays the parts for Activity Monitor has a green slice representing "Free" and I have observed that when that goes to very slim, my machine freezes up. At that point I have to reboot. HOWEVER, there was a system upgrade from 10.6.3 to 10.6.4 just now and my memory appears stable. So it may be that Apple has fixed some internal problem - the information about it (captured at https://infosecurity.us/?p=15251) is "resolve an issue that causes the keyboard or trackpad to become unresponsive". So it may be solved. I won't know for a while. Before the upgrade today it was getting low Free, now it's not ... with Seamonkey, Terminal and Skim running. For the record: Real mem 135.0 MB Private Mem 60.2 MB Shared mem 28.2 MB Virtual Mem 96.7 MB Threads 22
Bug 390944 explains why "leaks" gets confused, btw.
(In reply to comment #17) > Bug 390944 explains why "leaks" gets confused, btw. Thanks. See my comment over there ...
Closing as INVALID based on Comment 17
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.