Tracing from Generic to Specific

• 

  adamhill wrote:

  Second: How can I trace some generic allocated object like "byte[]" back to the object that actually allocated it? My specific question is/was a ImageBrush in WPF, but shows up in the object list as a byte[].
  
  Is there anyway to say "Just show me all ImageBrushes and the external bytes that were allocated from them?"

  
  We're working on a couple of features to help with this: at least one of these should show up in the next EA build, so you will be able to find things like only the byte arrays that are referenced by ImageBrushes and explore how objects of different classes relate to each other.
  
  We're not currently planning to have a feature that will show the place an object was allocated in this version: we're focusing much more on providing ways of exploring how objects relate to each other at the time that a snapshot was taken - this is because one of the primary goals of the memory profiler is to find out why an object is in memory now.
  
  It's also because the way .NET allocates and uses objects means that often the thing that allocates an object and the thing that actually uses it are separated by a long distance, so this information can be distracting and misleading - as a trivial example, an object that is assigned via a property would be 'allocated' by the object that did the assigning, but would be kept in memory by the thing it was assigned to. One more such assignment would completely obfuscate what happened if you only look at where it was allocated.
  
  This is inevitable due to the way .NET is designed. In languages like C++ the need to free objects up when they are finished means that usually the class that creates an object is responsible for ensuring that it is destroyed. In .NET the garbage collector means that there's no need for anything to take responsibility for most objects, so they become free to wander far from where they were initially created.

  Andrew H February 17, 2009 05:44

  - 0 +
• 
  Hi Adam,
  
  
  Thanks for posting. As Andrew says, we have a feature in development at the moment that will help with that, however in the meantime you might find this walkthrough useful:
  
  http://www.simple-talk.com/community/bl ... 71980.aspx
  
  I started off tracing back from a really low-level object, in this case a string, to find a leak in Exception Hunter. The strategy I suggest in the walkthrough is to look for byte []s that are a long way from a GC root (you can sort by this column in the object list), then pick one of them to analyse.
  
  Hope that helps.
  
  
  Thanks,
  
  
  Bart

  Bart Read February 17, 2009 07:07

  - 0 +

Add comment

Please sign in to leave a comment.