Pull/build from March 25, 1999. Solaris 2.6, gcc 2.7.2.3, etc. MLK: 34 bytes leaked at 0x867718 * This memory was allocated from: malloc [rtlib.o] __bUiLtIn_nEw [libgcc.a] __builtin_new [rtlib.o] __bUiLtIn_vEc_nEw [libgcc.a] __builtin_vec_new [rtlib.o] nsString::EnsureCapacityFor(int) [nsString.cpp:314] nsString::SetString(const unsigned short*,int) [nsString.cpp:817] nsString::operator =(const nsString&) [nsString.cpp:871] nsBaseAppCore::Init(const nsString&) [nsBaseAppCore.cpp:101] nsBrowserAppCore::Init(const nsString&) [nsBrowserAppCore.cpp:188] BaseAppCoreInit(JSContext*,JSObject*,unsigned int,long*,long*) [nsJSBase AppCore.cpp:167]

Re-assigned to rods@netscape.com. Rod, this looks to be in some of your original code.

This appears to be a leak in the nsString code. Not the AppCore code.

Rod -- you need to look deeper. I think the leak is technically caused by something in appcore allocating a string and never deleting it.

moving to m5

From what I can tell, it looks like this is because some nsAtoms are being created and never freed.

I've reworked the use of atoms by the file download dialog(s) so that they get created/destroyed as needed. When I move this code to its own service I'll use service loading/unloading to manage this. This will go in as soon as M4 is branched.

Bill, did this ever get into the tree? If so, can you please verify this one since you get to look at the code? thanks

Yes (pre-M4, as it turned out).