How to see the _REFERENCE properties

  • peterwagener

    peterwagener - 2007-08-06

    Hi Folks,

    First off, I want to thank you for putting together Drip and sIEve; those of us who are building complex DHTML applications that must run on IE6 are eternally in your debt.  It is always heartening to see volunteers step in to fill the vacuum left on the development tools side when certain unnamed companies refuse to acknowledge that their software has significant flaws in its design :)

    I have a question about how sIEve collects its data.  My testing cycle is typically to load up my application, check the 'Detect Cycles' box, then hit the 'about:blank' button and look at the leaked nodes that sIEve finds.  On some nodes, the Properties list will show a specific property, "_REFERENCE", which tells me where a reference to that node originally came from.

    This is incredibly useful info, especially for a complex application.  Using that info I can actually find where the outlying reference came from, and clean it up on the application unload to get rid of a circular reference.  However, the majority of leaked nodes in this situation don't have a "_REFERENCE" property at all.

    So, can you provide some details on how sIEve injects that property into some nodes, while not others?  Are there changes I could make to my application to help sIEve be able to track and report references?  Any info you could provide here would be priceless.

    Again, thanks for putting together such a useful tool.


    • Johan @ Cordys

      Johan @ Cordys - 2007-08-07

      Hi Peter,

      Tks. Why not showing all _REFERENCE paths?  The simple fact that the scanner for references can't detect closures. The scanner only iterates over all known properties. Eg. You have a construction with a closure:

      domObject.leak = addLeak(domObject);

      function addLeak(obj)
         return function()

      In the example the domObject.leak property points to a function (instance) holding a reference to 'domObject'.  This is a cycle and causing a leak. However the scanner is not able to detect that the instance of the function (created by addLeak(domObject)) refers to other objects.

      But the good news is that the same unnamed company fixed a bug in the garbage collector see:  The bad news however is that there are still leaks if you have cycles on 'orphan' nodes not attached to the html document DOM tree. A node will also become an 'orphan' when you unlink it with 'removeChild()'.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks