Jump to content
  • Advertisement
Sign in to follow this  
Idov

Accessing the heap and stack...

This topic is 3810 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi! I just wanted to know if there's any way to access the heap or stack using c++. or even better: Is it possible to receive a notification from the OS every time I try to access (read/write) the heap or the stack? [smile]

Share this post


Link to post
Share on other sites
Advertisement
Certainly you can "access" the heap and/or stack -- after all, locals are on the stack and objects allocated dynamically with new are on the heap, and so on. However that is about the limit of the 'access' you get with just standard C++.

To do anything more involved, such as walking the stack or heap, locking or compacting memory, and so on, will require non-portable OS functionality (for Windows see here, for example).

Getting a notification like you want will also likely involve extensive effort on your part, and isn't likely to be actually that useful, especially since it would be extremely brittle. You might begin by looking into setting up guard pages -- but you need to be careful with these sorts of things. This is the sort of thing you may need low-level, perhaps kernel-mode code for.

Why do you want to do this? Chances are it is not as useful as you think.

Share this post


Link to post
Share on other sites
thanks :)
I want to find buffer overruns, so if I keep a table of addresses and the pointers that point to them, I'll be able to know if one pointer is accessing another's space.

Share this post


Link to post
Share on other sites
Quote:

I want to find buffer overruns, so if I keep a table of addresses and the pointers that point to them, I'll be able to know if one pointer is accessing another's space.

That will not work the way you seem to think. The range of addresses that are valid for a location are the only addresses that can write to the location, you can't write to location 1000 "via" a pointer pointing to location 100, for example (a gross oversimplification, of course, but you should get what I mean).

There are better ways to do this -- in general you wrap new and delete, malloc and free, and such so that they indirect through your own allocation methods which add guard bytes to the end of each allocation. This can be done in standard C++ without any OS-level hackery, and it will have less of an impact on the existing code.

Even better, there are existing implementations of this kind of memory manager, such as the one by Paul Nettle (MMGR). You should use those rather than writing your own, because it is extremely non-trivial -- especially in the fashion you were originally planning. In particular, when you get it wrong, as you likely will if you've never done it before, you mostly get bad data that reports more or less leaks and overruns than you actually have, which means you mostly just wasted your time.

Even the built-in CRT memory debugging in Visual Studio is better than rolling it entirely yourself.

Share this post


Link to post
Share on other sites
Quote:
Original post by Idov
thanks :)
I want to find buffer overruns, so if I keep a table of addresses and the pointers that point to them, I'll be able to know if one pointer is accessing another's space.
A custom memory manager would be the best way to do this. You could then allocate some buffer space at each end of the allocation, and check if that buffer space is intact when you release the buffer.

It won't catch massive overflows, but it should be a good start.


EDIT: Too slow [smile]

Share this post


Link to post
Share on other sites
There's also another way to catch them - the functionality is already built into Windows. It's called "Page Heap Mode". What it does is make every allocation sit at the end of a virtual memory page, and mark the next page as invalid.

See http://support.microsoft.com/kb/286470 for details on how to make use of it.

The only downside is that it will use lots more pages than normal and may run you out of memory if you make lots of tiny allocations.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!