Solaris 2.6, gcc 2.7.2.3 .. current build as of the night of May 26, 1999. Might we not be closing prefs? MLK: 2210 bytes leaked in 85 blocks * This memory was allocated from: malloc [rtlib.o] JS_malloc [jsapi.c:730] js_InflateString [jsstr.c:2291] js_ExpandErrorArguments [jscntxt.c:310] js_ReportCompileErrorNumber [jsscan.c:517] PrimaryExpr [jsparse.c:2452] MemberExpr [jsparse.c:2147] UnaryExpr [jsparse.c:2068] MulExpr [jsparse.c:1931] AddExpr [jsparse.c:1913] ShiftExpr [jsparse.c:1898] RelExpr [jsparse.c:1866] EqExpr [jsparse.c:1841] BitAndExpr [jsparse.c:1829] BitXorExpr [jsparse.c:1818] BitOrExpr [jsparse.c:1807] AndExpr [jsparse.c:1796] OrExpr [jsparse.c:1785] CondExpr [jsparse.c:1745] AssignExpr [jsparse.c:1704] Expr [jsparse.c:1643] Statement [jsparse.c:1387] js_Parse [jsparse.c:231] CompileTokenStream [jsapi.c:1958] JS_CompileUCScriptForPrincipals [jsapi.c:2036] JS_EvaluateUCScriptForPrincipals [jsapi.c:2386] JS_EvaluateUCScript [jsapi.c:2371] JS_EvaluateScript [jsapi.c:2339] PREF_QuietEvaluateJSBuffer [prefapi.c:647] PREF_EvaluateJSBuffer [prefapi.c:632] * Block of 26 bytes (85 times); last block at 0x29caf8

Reassigning to mccabe, since this appears to be a js bug.

This looks like the usual JS pointer-bit-flipping stuff that confuses purify all the time. (We store the String pointer as myStrPtr | 0x04 to preserve type information.)

Does the same (sort) of leak show up when we visit pages with javascript in them? If so, then I'm inclined to agree with shaver. Seems possible though that the prefs code (which has its own javascript runtime?) might not be running a final gc.

I've seen these before and almost all of them have gone away as leaks of whatever held the runtime got fixed. I'm inclined to think it is not running a final GC or something like that.

For us more alphabetically challenged, the initials "GC" would stand for what?

GC stands for garbage collection. Pesky bugzilla - below comments have been bumped twice by this active thread. It seems likely that at least the context and runtime are freed... prefapi.c:519 has PREF_Cleanup, which has if (gMochaContext) JS_DestroyContext(gMochaContext); gMochaContext = NULL; if (gMochaTaskState) JS_Finish(gMochaTaskState); gMochaTaskState = NULL; ... so if PREF_Cleanup is called (which I haven't verified...), these are called. I'm not sure if a final GC gets run, though; JS_Finish just seems to free runtime-associated arenas without running a GC. Shaver claims that a GC is run after the last context is destroyed, but that this might not get rooted objects.

Whoops. Let's try looking at the backtrace before we make assumptions about what's going on, shall we? The leak occurs in js_InflateString when called by js_ExpandErrorArguments, called by js_ReportCompileErrorNumber. Looks like when we generate and populate an error report, we're allocating strings that never get freed. So there's no GC-hooey going on, this is an ordinary memory leak. Roger, I think you were the last person to work with the error reporting mechanism. Could you take a look at this? (adding myself to the cc: list). (and John - this is a side-effect of the error reporter being called 85 times when reading prefs (possibly to report a warning...) - were you aware of this?

No.

The parser's error handler wasn't blowing off the error report's internal message bits and pieces. Now it is. Also, a string being passed into the error reporter for misusing a reserved word wasn't being freed.

bruce, can you verify the fix?

Sure. It'll take me a couple of days though, I'm swamped here at work. anyone else have Purify in QA beyond the mailnews group?

I'll ask around and try to borrow a machine, perhaps. This is not a high priority to verify quickly, however, so no rush. Thanks.

bruce, I hear your back. Any luck on verifying this?

I'm not seeing a leak like this now and rogerl's fixes should've handled this one.

Moving all libPref component bugs to new Preferences: Backend component. libPref component will be deleted.