397305 - Leaking an nsStringBuffer+nsCStringArray (nsVoidArray) determining whether file paths start with a volume name

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Jeff Walden [:Waldo]]

Attachment: nsStringBuffer leak tree

URL and attached leak tree say it all; without this fixed RLk won't drop to 0 on the Mac tinderboxen.  With the patch from bug 397134 applied, these are the only leaks I see running RLk, but I've been getting slightly flaky results running the test, so I don't entirely trust a fix here plus a fix there to drop RLk to 0.

I don't know what the right fix is here to free the array at shutdown.  It may involve moving |net_GetFileFromURLSpec| into some utility class which can be allocated as a singleton in the IO service, or something like that.  In any case, I don't think we can localize a fix for this to just that function, and we're going to have to rejigger the way every platform does that test at least a little.

Comment 1

[Boris Zbarsky [:bzbarsky]]

The right fix here is to free this thing at shutdown.  In general, static objects with ctors (as here) are a really bad idea; for one thing, they prevent easy XPCOM restart.  So really, we should dynamically allocate it in the module ctor and destroy it in the module dtor.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

Comment 3

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 283252 [details] [diff] [review]
patch

r+sr+a=bzbarsky

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk.