Locating objects (structs) in memory - how to?

Question

Hi,

How would you locate an object in memory, lets say that you have a struct defined as:

struct POINT {
   int x;
   int y;
};

How would I scan the memory region of my app to find instances of this struct so that I can read them out?

Thanks R.

Answer 1

You can't without adding type information to the struct. In memory a struct like that is nothing else than 2 integers so you can't recognize them any better than you could recognize any other object.

Answer 2

You can't. You have to know the layout to know what section of memory have to represent a variable. That's a kind of protocol and that's why we use text based languages instead raw values.

Answer 3

You don't - how would you distinguish two arbitrary integers from random noise?

( but given a Point p; in your source code, you can obtain its address using the address-of operator ... Point* pp = &p;).

Answer 4

There's no way to identify that struct. You need to put the struct somewhere it can be found, on the stack or on the heap.

Sometimes data structures are tagged with identifying information to assist with debugging or memory management. As a means of data organization, it is among the worst possible approaches.

You probably need to a lot of general reading on memory management.

Answer 5

There is no standard way of doing this. The platform may specify some APIs which allow you to access the stack and the free store. Further, even if you did, without any additional information how would you be sure that you are reading a POINT object and not a couple of ints? The compiler/linker can read this because it deals with (albeit virtual) addresses and has some more information (and control) than you do.

Answer 6

You can't. Structs don't store any type information (unless they have virtual member functions), so you can't distinguish them from any other block of sizeof(POINT) bytes.

Why don't you store your points in a vector or something?

Answer 7

You can't. Something like that would probably be possible on some "tagged" architecture that also supported tagging objects of user-defined types. But on a traditional architecture it is absolutely impossible to say for sure what is stored in memory simply by looking at the raw memory content.

You can come closer to achieving what you want by introducing a unique signature into the type, like

struct POINT { 
   char signature[8];
   int x; 
   int y; 
}; 

and carefully setting it to some fixed and "unique" pattern in each object of POINT type, and then looking for that pattern in memory. If it is your application, you can be sure with good degree of certainty that each instance of the pattern is your POINT object. But in general, of course, there will never be any guarantee that the pattern you found belongs to your object, as opposed to being there purely accidentally.

Answer 8

Short answer: you can't. Any (appropriately aligned) sequence of 8 bytes could potentially represent a POINT. In fact, an array of ints will be indistinguishable from an array of POINTS. In some cases, you could take advantage of knowledge of the compiler implementation to do better. For instance, if the struct had virtual functions, you could look for the correct vtable pointer - but there could also be false positives.

If you want to keep track of objects, you need to register them in their constructor and unregister them in their destructor (and pay the performance penalty), or give them their own allocator.

Answer 9

What everyone else has said is true. In memory, your struct is just a few bytes, there's nothing in particular to distinguish it.

However, if you feel like a little hacking, you can look up the internals of your C library and figure out where memory is stored on the heap and how it appears. For example, this link shows how stuff gets allocated in one particular system.

Armed with this knowledge, you could scan your heap to find allocated blocks that were sizeof(POINT), which would narrow down the search considerably. If you look at the table you'll notice that the file name and line number of the malloc() call are being recorded - if you know where in your source code you're allocating POINTs, you could use this as a reference too.

However, if your struct was allocated on the stack, you're out of luck.