496557 - Fix some leaks/failures in test_filter.js

Status: RESOLVED FIXED

(MailNews Core :: Networking: NNTP, defect)

Description

[Mark Banner (:standard8)]

Attachment: The fix

With the patch applied from bug 438922, test_filter.js crashes due to bad access in the mork code.

I think this is basically because the backend is trying to tidy up whilst we're still holding onto things in the test e.g. keeping folders and databases open.

The attached patch fixes it.

Comment 1

[David :Bienvenu]

I'm curious if we can fix this w/o using forceDBClosed. I'd like to investigate this a bit before r+'ing it, because I'd like to understand what's going on a little bit more...it looks to me like we're holding onto both a header enumerator and a bunch of headers so nulling those out when done with them and doing a gc at the end should be sufficient. I'm talking in particular about testAction and testAttrib. Or maybe using let to declare those vars and doing a gc would be equivalent...

Comment 2

[David :Bienvenu]

It's actually the msg thread object that seems to be causing the issue for me, so the patch to cleanup the header enumerators won't be sufficient.

mork!morkRowObject::CloseRowObject+0x0000000000000068 (c:\mozilla-build\msys\tbirdhq\mozilla\db\mork\src\morkrowobject.cpp, line 606)
mork!morkRowObject::CloseMorkNode+0x000000000000002A (c:\mozilla-build\msys\tbirdhq\mozilla\db\mork\src\morkrowobject.cpp, line 86)
mork!morkRowObject::~morkRowObject+0x0000000000000033 (c:\mozilla-build\msys\tbirdhq\mozilla\db\mork\src\morkrowobject.cpp, line 94)
mork!morkRowObject::`scalar deleting destructor'+0x000000000000000F
mork!morkObject::Release+0x00000000000000D8 (c:\mozilla-build\msys\tbirdhq\mozilla\db\mork\src\morkobject.cpp, line 67)
mork!morkRowObject::Release+0x000000000000000D (c:\mozilla-build\msys\tbirdhq\mozilla\db\mork\src\morkrowobject.cpp, line 120)
msgdb!nsMsgThread::~nsMsgThread+0x000000000000007F (c:\mozilla-build\msys\tbirdhq\mailnews\db\msgdb\src\nsmsgthread.cpp, line 94)
msgdb!nsMsgThread::`scalar deleting destructor'+0x000000000000000F
msgdb!nsMsgThread::Release+0x00000000000000D3 (c:\mozilla-build\msys\tbirdhq\mailnews\db\msgdb\src\nsmsgthread.cpp, line 45)
xpc3250!XPCJSRuntime::GCCallback+0x000000000000054B (c:\mozilla-build\msys\tbirdhq\mozilla\js\src\xpconnect\src\xpcjsruntime.cpp, line

Comment 3

[David :Bienvenu]

folder.msgDatabase = null; 

would also fix this problem (or at least kick the can down the road) - the thread issue is the nsMsgDatabase caches the last nsgMsgThread object it returns, so that it can avoid creating the same nsMsgThread object over and over again. But nsMsgThread owns a reference to the db, so we have a cycle. nsMsgDBFolder:::SetMsgDatabase calls ClearCachedHdrs() on the db, which tells the db to clear its header cache and the thread cache, among other things. ForceDBClosed also does this, but it's a little more brute force.

Comment 4

[David :Bienvenu]

Attachment: alternate fix

Standard8, this fixes the problem for me - does it for you as well?

Comment 5

[Mark Banner (:standard8)]

Comment on attachment 381983 [details] [diff] [review]
alternate fix

Yep, much nicer. r=Standard8

Comment 6

[David :Bienvenu]

fix checked in.