Comments on: Now Where Did I Allocate That?! Unfortunately the easiest and most secure option, if you're using your own allocator at the end of the chain, is to stuff file&line somewhere before calling the standard library functionality and then use that for every allocation 'til it changes. To make it a macro though you'll lose the "call a method on an object" view of things: #define tracked_push_back(vec, item) mmgrTrackFileLine(__FILE__, __LINE__); vec.push_back(item) (Wrap with appropriate do/while, change names, but understand the point.) If you're using the system allocator, you could do something like this to track allocation info separately from the allocations themselves even, although obviously then you lose the easy discovery of the allocation record from the allocation itself. Unfortunately the easiest and most secure option, if you’re using your own allocator at the end of the chain, is to stuff file&line somewhere before calling the standard library functionality and then use that for every allocation ’til it changes. To make it a macro though you’ll lose the “call a method on an object” view of things:

#define tracked_push_back(vec, item) mmgrTrackFileLine(__FILE__, __LINE__); vec.push_back(item)

(Wrap with appropriate do/while, change names, but understand the point.)

If you’re using the system allocator, you could do something like this to track allocation info separately from the allocations themselves even, although obviously then you lose the easy discovery of the allocation record from the allocation itself.

]]>
By: Tom Plunket/2011/03/10/now-where-did-i-allocate-that/#comment-1550 Tom Plunket Sun, 13 Mar 2011 15:23:05 +0000 Ah - we do those for all crash reports. And there are enough of these that it makes a difference :) Ah – we do those for all crash reports. And there are enough of these that it makes a difference :)

]]>
By: Julien Koenen/2011/03/10/now-where-did-i-allocate-that/#comment-1489 Julien Koenen Fri, 11 Mar 2011 09:12:28 +0000 You might want to use the newer DIA functions instead of dbghelp.dll - it's *much* faster. (Especially important when symbolizing lots of callstacks) You might want to use the newer DIA functions instead of dbghelp.dll – it’s *much* faster. (Especially important when symbolizing lots of callstacks)

]]>
By: Julien Koenen/2011/03/10/now-where-did-i-allocate-that/#comment-1465 Julien Koenen Thu, 10 Mar 2011 21:35:10 +0000 I wanted to make this usable for as many platforms as possible, so Microsoft, Linux, etc. specific macros were avoided. For reference though I did find the following article about another person’s efforts to mimic the leak detection from MSVC++ on Linux Some libraries I've seen were nice and have macros that replace the calls to standard allocators and deallocators making the approach as easy as redefining the macros. For libraries where the standard allocators have been explicitly used you could probably use an approach similar to what Julien Koenen posts about above (hopefully Julien will write an article about it). Other than that I came across the following Powerpoint Presentation about changing the STL Allocators, but it definitely doesn't give you a file or line number to go look at: www.tantalon.com/pete/customallocators.ppt Mix that with Julien's approach, and you'll have the ability to track those wrapped allocations. Some libraries I’ve seen were nice and have macros that replace the calls to standard allocators and deallocators making the approach as easy as redefining the macros. For libraries where the standard allocators have been explicitly used you could probably use an approach similar to what Julien Koenen posts about above (hopefully Julien will write an article about it).

Other than that I came across the following Powerpoint Presentation about changing the STL Allocators, but it definitely doesn’t give you a file or line number to go look at: That sounds really cool. Any chance you might write an article on it? Where do you store the callstack that you are hashing? That sounds really cool. Any chance you might write an article on it?

Where do you store the callstack that you are hashing?

]]>
By: Paul-Laska/2011/03/10/now-where-did-i-allocate-that/#comment-1445 Paul-Laska Thu, 10 Mar 2011 18:30:59 +0000 You're absolutely right. I wasn't 100% sure when I originally wrote my code that all compilers on all platforms would guarantee static constant data from the macros, so I took the safe route and copied the data, and just haven't questioned it since. Looking at it now all I can do is facepalm and sigh. ;) Thanks for the tap on the shoulder, I'll work on updating my post once I get home from work tonight. Cheers! You’re absolutely right.

I wasn’t 100% sure when I originally wrote my code that all compilers on all platforms would guarantee static constant data from the macros, so I took the safe route and copied the data, and just haven’t questioned it since. Looking at it now all I can do is facepalm and sigh. ;)

Thanks for the tap on the shoulder, I’ll work on updating my post once I get home from work tonight.

Cheers!

]]>
By: Rachel 'Groby' Blum/2011/03/10/now-where-did-i-allocate-that/#comment-1438 Rachel 'Groby' Blum Thu, 10 Mar 2011 17:13:05 +0000 MSVC++ has a built-in debug heap. You can use #define _CRTDBG_MAP_ALLOC to report the line that called malloc. It’s also possible to
make it work for new.

]]> By: snake5/2011/03/10/now-where-did-i-allocate-that/#comment-1413 snake5 Thu, 10 Mar 2011 12:41:12 +0000 What we do here is we store a callstack with each allocation (actually we have a hash for the callstack). That frees you from changing the signature of the allocation call (and from using macros to do that) and it gives much better information (Because you have the whole callstack! ;) Regards Julien What we do here is we store a callstack with each allocation (actually we have a hash for the callstack). That frees you from changing the signature of the allocation call (and from using macros to do that) and it gives much better information (Because you have the whole callstack! ;)

Regards
Julien

]]>
By: artofcode/2011/03/10/now-where-did-i-allocate-that/#comment-1409 artofcode Thu, 10 Mar 2011 12:06:33 +0000

However, keep an eye on the way he overrides the new operator which can cause problems with code like STL.
Why are you using a character buffer to store the file path? The __FILE__ preprocessor macro gives a pointer to static constant data, you can just store that pointer... Why are you using a character buffer to store the file path? The __FILE__ preprocessor macro gives a pointer to static constant data, you can just store that pointer…

]]>