User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/522.11.1 (KHTML, like Gecko) Version/3.0.3 Safari/522.12.1 Build Identifier: 184.108.40.206 on osx simply start firefox, load NOTHING, you get a HUGE amount of memory leaks. Process 652: 189877 nodes malloced for 21104 KB Process 652: 4425 leaks for 355536 total leaked bytes. more information at http://pastebin.mozilla.org/181555 Reproducible: Always Steps to Reproduce: 1.Start firefox 2.open terminal 3.type "leaks firefox" Actual Results: Massive amount of leaked memory Expected Results: It shouldn't leak this much, safari opera and camino are nowhere near this amount dev tools needs to be installed on osx Also I was told by irc.mozilla.org to file this bug.
Is trunk better? Firefox 2.0.0.x is ancient, and a lot of progress has been made on leaks (as well as memory management in general). Grab a trunk nightly from here to test: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ If you find that the program |leaks| still reports leaks on trunk, stack traces for the allocations would be nice. Firefox comes with function-name symbols, so you should be able to get readable stack traces if you follow the instructions |leaks| gives.
Summary: OSX Memory Leak HUGE → [Mac] 350KB leaked, just launching and quitting
Trunk (https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/) is MUCH better, before leaks report 4800 plus leaks now its around 1200 leaks. """Firefox comes with function-name symbols, so you should be able to get readable stack traces if you follow the instructions |leaks| gives.""" I was not able to give the above information. the command "leaks firefox" gave me all the information possible. If there is any command you can think of that may give you this information, please share as I will report back with the results ASAP.
Try this: % /bin/sh $ $ MallocStackLogging=1 ./firefox Then, when you do a "leaks" on that process, you will see a lot more info. Do a "man leaks" in Terminal and there should be a bunch of information. This variable is described in the sixth paragraph on that page.
Okay, I think this is what you are looking for. http://www.sendspace.com/file/n2a128 (File was to big for pastebin and attaching to bug report) Please let me know if you need anything else.
In the future, please attach files to the bug report if at all possible; stuff tends to disappear when you put it elsewhere. If the attachment doesn't fit uncompressed, it's okay to compress it (gzip is fine).
zip is better, so we can access it using jar: URLs ;)
I created a fresh, empty profile and launched the app. After launch, leaks reports: % leaks 5375 Process 5375: 129124 nodes malloced for 16607 KB Process 5375: 1142 leaks for 46576 total leaked bytes. The profile is here: http://www.wykiwyk.com/mozilla/leakTesting/hg9c49v4.mozilla_20070924_184352_PDT.tgz The full leaks dump is here: http://www.wykiwyk.com/mozilla/leakTesting/leak_dump_bug390944.txt.
Could you try doing the same thing running Firefox with the environment variable MallocStackLogging set to 1? It's really difficult to tell what's being leaked without stack traces.
Sure, I can. Indeed, I blogged about how to do it (Feb 6) at http://xoatlicue.blogspot.com/2007_02_01_archive.html. I am using the newer nightly, 20070922, and am uploading a new dump with more information at http://www.wykiwyk.com/mozilla/leakTesting/leak_dump_bug390944_2.txt. Not that I mind doing this however many times it takes, but what did you see when you launched the browser? No leaks?
I can't run leaks because I don't have a Mac.
Rumor has it that "leaks" gets confused by the way SpiderMonkey stores pointers, and thinks things are leaked when they aren't. Use trace-malloc instead? :)
Those stack traces are impossible... I wonder what is making it mess up the stack traces?
"leaks" gets confused by tagged pointers, yes, since it does pointer-scanning. So a lot of SpiderMonkey data storage it will think is a leak, as well as a lot of nsAttrValue data storage. Unless you're filtering out the relevant things, the "leaks" output is more or less worthless. I did spend some time fixing real leaks that "leaks" caught, and last I checked I'd gotten them all on trunk. At least the ones it _can_ catch. If we're leaking some of the tagged stuff, there's no way to detect that with "leaks". I'd say this bug is invalid unless someone posts a log with the tagged pointers filtered out.
Hm. A yummy new page: http://developer.mozilla.org/en/docs/Debugging_memory_leaks (to do, figure out to get an RSS feed of devmo content....) The leaks tool gives one so much information. It is so useful in other apps. It is a shame that it cannot be made useful for FF. Should I go ahead and put a note in the page above pointing out that the leaks tool should not be used? It sounds as though this bug should just be marked invalid, yes? But I did not create it, so I will let someone else do it.
Who said that "leaks" shouldn't be used? It should be used if desired. We've fixed a number of leaks using it. You just have to know what it is and isn't telling you, and it has a number of false positives in Firefox.
Is there any documentation which can help one figure out what is a real leak and what is not? Is there a way to recognize a tagged-pointer entry that looks like a leak?
Even better would be a tiny python script to post-process |leaks| output.
Or a script to call it? I could provide some obvious function names to pass to --exclude. That seems like a much better approach than post-processing.
Yes, that would be great.
OK, this approach really doesn't work. The issue is that -exclude takes a function name such that if that name is on the allocation stack the allocation is ignored. So you have to add one -exclude for each relevant allocation location. But the thing that confuses "leaks" is storage, not allocation. So as soon as someone else takes over the pointer ownership and tags it "leaks" thinks it has leaked. And if all you can do is mark allocation locations it's whack-a-mole. For example every single function that can allocate a JSString needs to be marked (I stopped when I realized this). And of course that would mean that other (real) leaks in those functions would pass unnoticed. This is what I have so far, but this is barely the tip of the iceberg: # GetPropertyTreeChild: data stored in tagged chunks # js_NewRegExp: sets a JS private # InitExnPrivate: sets a JS private # CSSParserImpl::ParseStyleAttribute: attr storage is tagged # nsAttrValue::ParseAtomArray: attr storage is tagged # define_JavaPackage: sets a JS private # nsAttrValue::EnsureEmptyMiscContainer: attr storage is tagged # nsRuleNode::ConvertChildrenToHash: rulenode hash storage is tagged # nsRuleNode::Sweep: rulenode hash storage is tagged # nsRuleNode::Transition: rulenode hash storage is tagged # nsXULDocument::AddBroadcastListenerFor: nsSmallVoidArray uses tagged pointer # ProcessCharSet: stored on JSRegExp private leaks -exclude GetPropertyTreeChild -exclude js_NewRegExp -exclude InitExnPrivate -exclude 'CSSParserImpl::ParseStyleAttribute(nsAString_internal const&, nsIURI*, nsIURI*, nsIPrincipal*, nsICSSStyleRule**)' -exclude 'nsAttrValue::ParseAtomArray(nsAString_internal const&)' -exclude define_JavaPackage -exclude 'nsAttrValue::EnsureEmptyMiscContainer()' -exclude 'nsRuleNode::ConvertChildrenToHash()' -exclude 'nsRuleNode::Sweep()' -exclude 'nsXULDocument::AddBroadcastListenerFor(nsIDOMElement*, nsIDOMElement*, nsAString_internal const&)' -exclude 'nsRuleNode::Transition(nsIStyleRule*, unsigned char, unsigned char)' -exclude ProcessCharSet I did find one real leak in the process: bug 397716.
Greg, I'm marking this bug as invalid, but it would be great if you could test with a tool that doesn't get confused by tagged pointers. For a generic tool, that would probably require looking for leaks only at shutdown. Trace-malloc is probably your best bet if you're looking for simple leaks, but see http://wiki.mozilla.org/Performance:Leak_Tools for other options.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Summary: [Mac] 350KB leaked, just launching and quitting → The Mac OS X "leaks" tool reports 350KB of leaks with a just-launched Firefox
How about writing to Apple to get them to modify the leaks program so it does not report incorrect things? The claim on the leaks man page is "The leaks reported will always be true leaks." which is not true if as Boris Zbarsky says "it has a number of false positives in Firefox."
(In reply to comment #22) > How about writing to Apple to get them to modify the leaks program so it does > not report incorrect things? The claim on the leaks man page is "The leaks > reported will always be true leaks." which is not true if as Boris Zbarsky says > "it has a number of false positives in Firefox." I say this because of bug 571392 where I reported the same issue with SeaMonkey.
The man page is a little misleading, yes. I think the sentence "The leaks reported will always be true leaks." is meant to apply only to pure Carbon apps. Another part of the man page says "The -exclude option allows you to ignore functions that allocate memory which is from a well-known leak that you don't want to keep hearing about, or might be falsely labelled a leak by leaks."
Filed rdar://8115187 on the misleading man page.
You need to log in before you can comment on or make changes to this bug.