[sldev] [VWR] Heap checkers

[Brad Kittenbrink (Brad Linden)]

Robin Cornelius wrote:
> The issues with the utilities are run time speed, the really through
> checkers which put pages boundaries between allocs are very very slow
> and use lots and lots of memory. I have not so far been able to get
> duma to even get to the viewer logon screen. tcmalloc runs with out
> heapcheck but with heap check gtk threads barfs and the viewer will
> not start. The other issue is that if the run time speed IS that bad
> the viewer will never hold a connection to the server and getting
> fully in world is really a requirement, any ideas here on how to
> resolve this? the Microsoft heap checker has so far not caught
> anything, including case study 1 above and also fails to get in/stay
> in world (due to viewer execution speed) 4/5 times.
>
> tcmalloc's heap monitor does produce some interesting info that could
> help catch memory leaks or profile the viewers memory usage, see
> output at http://www.byteme.org.uk/heap/
>
> Regards
>
> Robin
I'm very happy about the discovery of those 2 specific corruptions, I'll 
be looking into how to follow up on those shortly.

Internally we've been investigating using tcmalloc on windows.  Our 
tests with heap checking enabled have resulted in framerates of about 
4-5fps once logged in.  We haven't focused as much on non-windows 
platforms yet, frankly because replacing the allocator is likely easier 
there.  From what I recall, we didn't run into any problems with 
tcmalloc on linux / OS X, but I'll double check on that.  I'm very 
curious about the gtk thread issue you mention.

However, our main goal is to decouple the viewer from smartheap on 
windows, so we can easily swap among any of several allocators with 
various debugging features whenever we'd like.  The main thing holding 
this up is that because of smartheap, all of our upstream libraries have 
had to be built against the static microsoft libc implementation.  
Reconfiguring all of them to build against the dll libc implementation 
has been time consuming.

Anyways, things on that front are wrapping up, and I'm hoping my library 
work can get in before the 1.21 viewer freezes,  but we'll see.  Either 
way, I expect we'll be working hard on exactly these kind of issues 
during the 1.21 RC series.

-Brad