After part 2 of bug 438922 has landed to clean up the leak logs, there will be remaining this leak for test_nsIMsgFolderListenerLocal.js: == BloatView: ALL (cumulative) LEAK STATISTICS |<----------------Class--------------->|<-----Bytes------>|<----------------Objects---------------->|<--------------References-------------->| Per-Inst Leaked Total Rem Mean StdDev Total Rem Mean StdDev 0 TOTAL 32 300 14854 6 ( 154.83 +/- 189.83) 51433 6 ( 147.76 +/- 230.17) 28 morkObject 44 132 482 3 ( 54.63 +/- 15.37) 1367 3 ( 76.51 +/- 20.84) 29 morkRowObject 56 168 97 3 ( 17.40 +/- 4.96) 127 3 ( 17.05 +/- 5.46) This is most likely a test harness issue, however I couldn't see anything obvious to fix it so filing the bug.

I'll look at this...

interestingly, I think the test is shutting down before the copies have unwound - I'm hitting nsCopyMessageStreamListener::OnStartRequest() after I do quit(); from check-interactive. I'll investigate...

two of the headers are from the local inbox, one is from the trash.

actually, the leaking ones seems to come from inbox/folder 2/folder 3 - these are eventually deleted to the trash, but there are still outstanding references to the headers. When the headers are deleted from inbox/folder 2/folder 3, they have a ref count of 6 or 7, which seems pretty high - the js test code is still holding them in an array, but that doesn't account for all the references.

test_folderCompact.js has the same kind of leak, which isn't surprising since some of the code is cloned, in particular, the delete messages code. I'm not sure at this point if the leak is coming from the backend or the test harness, so I'm going to try to drill down on it some more.

this test, reduced from the folder compact test, leaks a single header. This is as minimal as I could get it, e.g., removing the compact test at the end makes the leak go away (though other tests that don't have compaction have the same leak, so it's not compaction per se).

This was an actual leak, though not that common, I believe. Basically, if we get to closing the db and various client code hasn't freed up their headers, the last chance code that clears what's about to become a dangling mdbRow wasn't releasing the row. JS code in particular, because of garbage collection, is much more likely to cause this leak. This patch makes 3 more tests (I think) leak free.

I'll go see if I can figure out why the imap tests are still leaking so badly.

Comment on attachment 384152 [details] [diff] [review] proposed fix This also explains why adding a free of the global variable just before we finished (as I did in some other bugs) meant it "fixed" the leaks. r/sr=Standard8

fix checked in.

(In reply to comment #9) > This also explains why adding a free of the global variable just before we > finished (as I did in some other bugs) meant it "fixed" the leaks. (Might want to undo these "workarounds"?)

(In reply to comment #13) > (In reply to comment #9) > > This also explains why adding a free of the global variable just before we > > finished (as I did in some other bugs) meant it "fixed" the leaks. > > (Might want to undo these "workarounds"?) I thought about that, and decide it wasn't necessary. We have some tests which do both varieties so we're covered anyway.