[sldev] [VWR] Heap checkers

[Palmer Truelson (Zen Linden)]

Brad Kittenbrink (Brad Linden) wrote:
> 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.  
Slight correction.  I ported the heap profiler, not the heap checker to 
windows  Might be worth getting the checker up and going in windows and 
see what hell breaks loose.  The profilier found one pretty serious leak 
that would rear it's head sporadically, but the stack trace gave little 
info as to what library it was coming from.  It seemed to be related to 
a leak in the ATI drivers that bao is investigating.
> 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.
>
I had to make a couple of changes to mozilla to get tcmalloc to run in 
OS X and those changes should be in the latest llmozlib. And I think we 
had to reimplement strdup also (Gah! I feel so dirty!).  Also, Sardonyx 
and Tofu a few months back noticed occasional, inexplicable crashes when 
running tcmalloc with the linux viewer around a year ago but had 
problems reproducing it reliably.  But I haven't noticed any strange 
crashes when I've run tcmalloc in linux.  I have not run the viewer in 
OS X or linux with tcmalloc all that much, though.
> 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.
We also have a meeting in the SF office with Intel this Monday where 
Steve, Mani and I will be talking to some of their engineers about using 
their memory checker, threading building blocks (TBB), and thread 
advisor.  I really liked their TBB tools the first time I saw them, so 
maybe we'll have better luck catching more of these problems using their 
tools.

Anyway, thanks for looking into this and sharing all your info.  I'm 
really excited to find out what happens when cleaning up the issues you 
mentioned, Cornelius.

Palmer