build 2001080303, Modern theme, Win98 and Win2K Memory management is "deep waters" for me but I think it would be better to file a bug instead of submitting another one comment in n.p.m. performance. Anyway, after searching mlk bug list, I failed to find a bug for the behaviour below, although it seems to me it's evident there is a big problem here. Steps to reproduce: 1. Use a "spy" application to monitor Mozilla memory usage. 2. Set home page to blank, sidebar and personal toolbar to be not visible. Open a browser window and start hovering on all menu items (except Bookmarks). Be sure to browse the entire menu hierarchy. Memory is increased by 1.1-1.3 MB approx. 3. Open a new window and repeat menu browsing, as suggested above. There will be another 1.1-1.3 MB increase. 4. Repeat the same for subsequent blank new windows. Memory is always increased by the same amount, when browsing the menu hierarchy on this window. 5. Repeat the same for the bookmarks menu. Depending of the size of bookmark file being used (mine contains 430 bookmarks organised in various folders and subfolders), you get an even larger increase (I was consistently measured 2.9 MB). Memory usage continues increasing and increasing without using anything but blank browser windows ! (ommitting new window initial memory footprint which is another 1.1-1.2 MB). I noticed similar behaviour in Mail&News client. And the leaked memory is not completely returned to the system after closing all visible windows (-turbo mode). My first thought was that all the above are results of the menu cache but it can't be so large. Besides that, Mozilla should use the same cache for every new window. I saw that IE 5.5 also increases it's memory usage when browsing the menus. But the effect is temporary. After a few seconds, IE returns this memory to the system. Moz browser behaviour on this aspect contributes in making Mozilla less usable for memory constraint users. At least for those who surf with more than one browser windows at a time and /or use -turbo mode.

can you please use one of the leak monitoring tools to find out what actual classes are leaking? this bug might belong to bookmarks or toolkit/widgets: menus, but i'm giving it to waterson since i think he instruct you to use the leak tools.

I am ready :) But, before starting to learn such things like Purify (is demo version working ?), Leaky, Bloat detector etc, I would like to know if this bug is valid or it is utterly bs. Using rough tools like the OS monitor utilities (Sysmon for Win98, TaskMan for Win2K) it seems that available free memory is reduced when browsing the menu. Anyone else to confirm ?

looks valid to me. Following your steps my mem usage eventually hit around 3 meg and probably would have drifted higher if allowed. Confirmed. win NT4 2001082303 trunk

If you have a bookmark list long enough to scroll, then the memory leak is quite obvious. I took a WinNT box and fired up System Monitor to watch private bytes used by mozilla.exe. Memory usage will continue to increase as long as the bookmarks are scrolled. This is with 2001111903

Just spent some time looking at this: setting XPCOM_MEM_LEAK_LOG revealed no leaks. Menus and trees are both built lazily, so it is reasonable that memory usage will increase as you use them. Note that this memory won't be released until the window is closed (and even then, Windows `Task Manager' or `top' on Unix may not show a decrease in RSS, due to heap fragmentation). Resolving INVALID: there is no leak here.

The point of this bug wasn't the nature of memory bloat but the bloat itself. If it isn't a leak (I 'm still trying to make Purify work with Mozilla), that's good. But the footprint does increase rather abnormally. It doesn't sound good for Mozilla to increase memory usage for every window, by simply using the same menu and bookmarks. Tempting to reopen as "Footprint increases dramatically when browsing menu hierarchy and bookmarks"...no. Still thinking it's an issue, though.

tever is not RDF QA anymore