Windows port: calloc_crt should be hooked as well as malloc/free/calloc/realloc

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use libtcmalloc_minimal.dll for a program that uses (indirectly) calloc_crt
2. Notice that libtcmalloc is not used to allocate the object

What is the expected output? What do you see instead?

I would expect to find that the allocated memeory comes from the memory managed 
by libtcmalloc. However it comes from the default C Runtime heap.

What version of the product are you using? On what operating system?

1.9.1 on Windows XP using MS Visual Studio 2003, 2005 and 2010.

Please provide any additional information below.

The problem is that the Microsoft C runtime exports a bewildering  variety of 
entry points to the C runtime. Most of the entry points are wrappers for the 
underlying malloc/free/realloc calls which are already hooked. One exception is 
calloc_crt as this is implemented in terms of _calloc_impl in the MS c runtime 
(See calloc.c in "C:\Program Files\Microsoft Visual Studio 8\VC\crt\src")

The issue does not *break* anything since when the memory is later freed 
libtcmalloc falls back to the original C runtime free function, but it does 
affect memory statistics obtained using SetNewHook/SetDeleteHook as the delete 
hook is called twice for each such free.

I have locally fixed the issue by changing patch_functions.cc

- adding k_CallocCrt to the enum in class LibcInfo 

- adding calloc_crt to the list of function names listed in 
LibcInfo::function_name_[] array

- adding (GenericFnPtr)&::calloc to the list of functions in 
LibcInfoWithPatchFunctions<T>::perftools_fn_[]

- adding (GenericFnPtr)&Perftools_calloc to the list of functions in 
LibcInfoWithPatchFunctions<T>::perftools_fn_[]

The modified file is attached with 'rogero' marking these four changes.

Note that the other _crt exported entry points do not need special treatment as 
they simply forward to an already hooked underlying function.

Original issue reported on code.google.com by roger....@gmail.com on 17 Jan 2012 at 3:14

Attachments:

• patch_functions.cc

[GoogleCodeExporter]

Ugh, I was warned about this kind of stuff when I wanted to support patching in 
the first place. :-(  There's no guarantee that a new version of the crt won't 
have a different call pattern that will break things again either, is there?  
Sigh.

Are the only changes to the file the 4 lines you marked 'rogero'?  If so, it 
seems like a simple enough fix.  I'll pass it by our local windows expert and 
get it checked in if there are no gotchas.

While this is a pretty trivial change, can you sign the CLA at
   http://code.google.com/legal/individual-cla-v1.0.html
if you haven't already?

Original comment by csilv...@gmail.com on 17 Jan 2012 at 7:11

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 26 Jan 2012 at 1:10

• Changed state: Started

[GoogleCodeExporter]

This should be fixed in perftools 1.10, just released.

Original comment by csilv...@gmail.com on 31 Jan 2012 at 7:18

• Changed state: Fixed