Evergreen

Bug #1086458
Comment #25

Comment 25 for bug 1086458

Revision history for this message

Galen Charlton (gmc) wrote on 2013-01-19:

#25

example dump showing event listeners referring to ghost patron forms Edit (239.9 KiB, text/plain)

I have pushed a couple patches to the collab/gmcharlt/lp1086458_clean_up_after_some_event_listeners branch in the working/Evergreen repository that in *very* preliminary testing appear to avoid the memory leaks associated with the patron search form.

They operate by making sure that two sets of event listeners are removed when the relevant form is unloaded:

- double-click handlers for patron search results
- focus handlers for the patron display form

Of the two, the first seems to be the most important.

What lead me to this was analysis of cycle collector heap dumps. After running through the process described in my previous comment, the raw dump included the following line:

10919000 [rc=3] nsDocument normal (XUL) oils://remote/xul/rel_2_3_1/server/patron/summary.xul?id=7

Since that tab had been closed and shouldn't have been hanging around, I used Andrew McCreight's heapgraph tools (https://github.com/amccreight/heapgraph/tree/master/cc) to take a look:

python heapgraph/cc/find_roots.py /home/gmc/cc-edges-2.7900.log 10919000

The attachment is the output of that. The first section appears to indicate that an event listener from the search results is hanging on to the patron summary:

1425C4C0 [nsGenericElement (XUL) treecol id='billing_aua_within_city_limits' oils://remote/xul/rel_2_3_1/server/patron/search_resu
lt.xul]
    --[[via hash] mListenerManager]-> 1425C740 [nsEventListenerManager]
    --[mListeners[i] mListener]-> 14256BC8 [nsXPCWrappedJS (nsIDOMEventListener)]
    --[mJSObj]-> 1435E4E0 [JS Object (Function)]
    --[]-> 12E52B80 [JS Object (Call)]
    --[]-> 1430EF40 [JS Object (Object)]
    --[]-> 139B21C0 [JS Object (XULElement)]
...
    --[mNodeInfo]-> 157278B0 [nsNodeInfo (XUL) grid]
    --[mOwnerManager]-> 0B7C38E0 [nsNodeInfoManager]
    --[mDocument]-> 10919000 [nsDocument normal (XUL) oils://remote/xul/rel_2_3_1/server/patron/summary.xul?id=7]

After applying the patches, this stopped happening.

The double-click handler was added in 2.2, but I speculate that something changed in XULRunner's garbage collector. In any event, if I'm on the right track, a complete fix will entail making sure that all event listeners are cleaned up with removeEventListener() when they're no longer required.

Testing of these patches would be greatly appreciated .. I know they're not elegant.

They operate by making sure that two sets of event listeners are removed when the relevant form is unloaded:

- double-click handlers for patron search results
- focus handlers for the patron display form

Of the two, the first seems to be the most important.

What lead me to this was analysis of cycle collector heap dumps.  After running through the process described in my previous comment, the raw dump included the following line:

10919000 [rc=3] nsDocument normal (XUL) oils://remote/xul/rel_2_3_1/server/patron/summary.xul?id=7

Since that tab had been closed and shouldn't have been hanging around, I used Andrew McCreight's heapgraph tools (https://github.com/amccreight/heapgraph/tree/master/cc) to take a look:

python heapgraph/cc/find_roots.py /home/gmc/cc-edges-2.7900.log 10919000

The attachment is the output of that.  The first section appears to indicate that an event listener from the search results is hanging on to the patron summary:

After applying the patches, this stopped happening.

The double-click handler was added in 2.2, but I speculate that something changed in XULRunner's garbage collector.  In any event, if I'm on the right track, a complete fix will entail making sure that all event listeners are cleaned up with removeEventListener() when they're no longer required.

Testing of these patches would be greatly appreciated .. I know they're not elegant.