0

I would like to know how, given any chunk of memory, like an instance of a class or an std::vector, I can deduce which function ( which is probably from the *alloc family of functions ) allocated that given piece of memory or even better, which call to new or an allocator, if used, created that addressable space in my application .

user2485710
  • 9,451
  • 13
  • 58
  • 102
  • Out of the box it is impossible. You can create your own custom allocation scheme that keeps track of that. – dtech Nov 09 '14 at 00:48
  • You pretty much have to write the allocator so it allocates some extra space, and records data in that memory to identify the allocator (e.g., the allocator's address). – Jerry Coffin Nov 09 '14 at 00:49
  • @JerryCoffin not that a mere address would do any good without some extra information what is at that address. – dtech Nov 09 '14 at 00:50
  • 1
    @ddriver what do you mean with "out of the box" ? Isn't something like `gdb` able to do just that ? Or `valgrind` with some reverse engineering ? – user2485710 Nov 09 '14 at 00:50
  • possible duplicate of [How to determine if returned pointer is on the stack or heap](http://stackoverflow.com/questions/16709946/how-to-determine-if-returned-pointer-is-on-the-stack-or-heap) – Captain Obvlious Nov 09 '14 at 00:51
  • @JerryCoffin what if something slips out and there are parts of my applications that end up not using my allocator ? How I can see that clearly ? – user2485710 Nov 09 '14 at 00:51
  • Then you have a problem. – Jerry Coffin Nov 09 '14 at 00:52
  • @user2485710 - if I had to guess, I'd assume they use custom allocators which keep a registry of every allocation with information about it. As I said it is doable, but with standard `new` or "out of the box" it is not possible to tell what allocated that memory. Note that you can still overload the default `new` and plug your tracking there, but then objects with custom allocators might miss it. – dtech Nov 09 '14 at 00:52
  • @JerryCoffin nice, really no one in C and C++ never solved/had this problem with a solid sounding tool ? I'm the first asking this while retaining some degree of invariance ? – user2485710 Nov 09 '14 at 00:57
  • There are lots of tools, but you can cause problems for any/all of them if you work hard enough to bypass what they provide. – Jerry Coffin Nov 09 '14 at 00:59
  • @JerryCoffin which basically means there is no tool that can provide this "debug feature" as an invariance and a sounding 100% rate of success ? I wasn't expecting so much "loosness" over such a critical concept like memory and allocations . – user2485710 Nov 09 '14 at 01:04
  • @ddriver the problem is that you still need a backup plan for when another user of your codebase is using something different, a different allocator, or you just forget about it or you are using old code written 1-2 years ago, etc etc ... that's the point of me searching for such tool , it should help me, I shouldn't help it . – user2485710 Nov 09 '14 at 01:06
  • Have you tried to think through what it would take to assure a 100% chance of success? There's only one way to truly get to 100%--run the code inside a virtual machine. Anything else leaves at least some chance of being bypassed. – Jerry Coffin Nov 09 '14 at 01:17
  • @JerryCoffin indeed, but how, the fact I can imagine it doesn't mean I can run it, I was thinking about a similar solution but can't really associate that with any existing tool that I know of . I don't even care about testing for performances at this point, I just want to check memory patterns and memory allocations . – user2485710 Nov 09 '14 at 01:37

2 Answers2

2

The C/C++ memory allocator does not keep track of this piece of data — it only keeps track of the size of each allocated area. There is no way to find out who allocated it.

If you want a more constructive answer, you will need to tell us what you're trying to achieve. If the goal is to debug your code, then you should be using a third-party memory debugger — valgrind is probably the best one available right now.

jch
  • 5,382
  • 22
  • 41
  • there is 1 big problem with `valgrind` which is basically why I don't use it anymore now that I have sanitizers for pretty much everything I can debug upfront; All `valgrind` does, it does because of reverse engineering and not because it relies on some particular ABI/fileformat like DWARF that delivers accurate and precise debug informations . – user2485710 Nov 09 '14 at 12:47
0

There are some profiling tools, such as strace which shows you the functions being called.

Paul92
  • 8,827
  • 1
  • 23
  • 37
  • that is an equivalent of an "educated guess", in a multithreaded or concurrent accessed world it would just be a mess . – user2485710 Nov 09 '14 at 00:55