0 Replies Latest reply on Nov 16, 2007 6:44 AM by snowymike

    understanding loitering objects and back references in profiler

    snowymike
      i'm trying to debug a problem in my AIR app that results in exhaustion of USER objects (USER objects are viewable in the sysinternals tool process explorer) on my windows xp sp2 system. once the USER objects for my AIR app grow to a certain number (between 2000 and 3000) i'm unable to open new windows on my computer.

      i'm using the profiler in flex builder 3 beta 2 to help troubleshoot this problem. i take a memory snapshot, then interact with my AIR app and watch the USER objects count climb, then take another memory snapshot. i then click "Find Loitering Objects". that opens up a Loitering Objects tab - i'm guessing that these loitering objects are responsible for the USER objects climb.

      most of the Loitering Objects are not my classes, but a few are. Regex and RegexEditor, two model classes of mine, show an Instance count equal to the total number of Instances i'd expect to have been created between the two memory snapshots. if my app was correctly functioning i'd expect the count for each to show 1, not <n> where <n> is the number of times a new instance of these objects is created. that leads me to believe that somewhere in my code i'm hanging on to a reference to these objects, preventing them from being garbage collected (i've tried clicking the Run Garbage Collector link in the profiler, which doesn't decrease the count of these objects). the Regex class extends EventDispatcher, so there certainly could be a programming error on my part (e.g. not removing event listeners) that could prevent these objects from being garbage collected.

      however, when i double click Regex in the Loitering Objects view to view the Object References, i only find a single back reference to RegexEditor. all other Regex instances have no back references, yet they remain in memory. no RegexEditor instance has a back reference, which doesn't make sense either - there is definitely a reference to one instance of this class in my application. i don't see any back references to view classes, which doesn't make sense to me either, since there is a view class that binds to the property values of Regex.

      perhaps i fail to understand what back references mean in the profiler. could someone clarify this for me? my best hope for diagnosing the leak was to find the unexpected back references and make sure i clean those up. any other suggestions for diagnosing my problem?

      thanks.