Closed Bug 15864 Opened 20 years ago Closed 20 years ago

[MLK] selecting server causes mail data sources to leak

Categories

(MailNews Core :: Backend, defect, P3)

All
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: Bienvenu, Assigned: Bienvenu)

References

Details

Attachments

(1 file)

If I startup and shutdown mail news w/o selecting anything, all our datasources
are freed. Similarly, if I expand a server w/o selecting it, all our datasources
are freed. But if I select a server, we leak the datasources. This is because we
leak an nsXULTreeElement, as near as I can tell. I'm still investigating, but
here's the memory leak report:

Type                                     # created       # leaked
----                                     ---------       --------
RDF_InMemoryDataSource                   17              5
RDF_RDFContainerUtilsImpl                1               1
RDF_Assertion                            823             643
RDF_LiteralImpl                          667             192
nsBaseWidget                             39              1

I'm going to see if rerooting the tree is what's causing this, or just the act
of selecting.
DeviceContextImpl                        8               1
nsWebShell                               6               1
RDF_DateImpl                             117             103
RDF_RDFXMLDataSourceImpl                 7               2
AtomImpl                                 13908           180
StyleContextImpl                         298             15
RDF_LocalStoreImpl                       1               1
RDF_nsXULContentUtils                    1               1
RDF_RDFElementImpl                       690             38
RDF_nsXULAttribute                       1675            107
nsMsgAccountManagerDataSource            1               1
nsMsgFolderDataSource                    1               1
RDF_nsXULKeyListenerImpl                 1               1
RDF_CompositeDataSourceImpl              9               1
RDF_nsRDFDOMNodeList                     901             2
RDF_nsXULTreeElement                     5               1
nsMsgFolder                              135             135
Status: NEW → ASSIGNED
Target Milestone: M14
I disabled the tree rerooting code, and we stil leak. This is good news, I
think, since it means it's most likely the tree selection code. But I've been
wrong before...
Attached file memory leak analysis
Notice that we leak a web shell in the second case.
I think the web shell leaks because the data source leaks - our datasources hold
onto a msg status feedback object, which hold onto a web shell. Perhaps this
causes some circularity in some situations. I can look at making one of these a
weak ptr, probably the web shell held onto by the msg status feedback object.
so much for that theory - making the msg status feedback not hold onto the web
shell or dom window didn't fix anything.
I've traced this down some more - we leak one nsEventStateManager, which is
holding onto some content nodes when you do a selection. These all tend to be
an RDFElementImpl, which holds onto the usual littany of suspects, composite
datasources, our datasource, etc. I believe we leak the nsEventStateManager
because we leak a web shell - this seems highly circular. Also, the
nsEventStateManager code is highly suspicious. It doesn't use nsCOMPtr's, and
often assigns to interface pointers without releasing the original value.
add joki to cc list. tom: any ideas?
OK, I was a fool to think I could fix this. I'm going to try to ameliorate the
damage done by adding a Close method to our datasources and calling it from the
RDF shutdown notification. The close method will just null out our nsCOMPtrs,
which tends to fix all the leaks caused by the ds leaks, which is something,
anyway.
Blocks: 16654
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
I'm not seeing this leak anymore - it must have gotten fixed by someone!
ok, I'll mark verified since David B. reported the bug and is not seeing this 
any longer.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.