Check if a pointer points to allocated memory on the heap

Question

I want to know if a pointer points to a piece of memory allocated with malloc/new. I realize that the answer for an arbitrary address is "No you can't" but I do think it is possible to override malloc/free and keep track of allocated memory ranges.

Do you know a memory management library providing this specific tool?
Do you know something for production code?

Valgrind is great, but it is too much instrumentation (slow) and as Will said we don't want to use Valgrind like this (making the soft crash is good enough).
Mudflap is a very good solution, but dedicated to GCC, and sadly, a check does not simply return a boolean (see my answer below).
Note that checking that memory writes are legal is a security issue. So looking for performance is motivated.

Solution 1

There's no standard way to do this, but various malloc debugging tools may have a way of doing it. For example, if you use valgrind, you can use VALGRIND_CHECK_MEM_IS_ADDRESSABLE to check this and related things

Solution 2

You can do this yourself, if performance is not a real issue for your application:

Define MyMalloc(...) and MyFree(...) in which, along with calling malloc/free, you update a (ordered)list of pairs {address -- the result of malloc, blockSize -- the amt of memory requested }. Then when you need to check a pointer p, you look for a pair satisfying: address <= p <= address + blockSize.

Other conditions could/should be checked, if you want to actually use that pointer, this will only tell if an address is in use or not.

Solution 3

Mudflap (for gcc) seems very sweet. You have to compile your soft with but it will check any wrong pointer access (heap/stack/static). It is designed to work for production code with slowdown estimated between x1.5 to x5. You can also disable check at read access for speedup.
User check can be performed using

void __mf_check (void *ptr, __mf_size_t sz, int type, const char *location)

Calling this function results to: nothing, fork to gdb, segv or abort depending on environment parameters.

Solution 4

You can use LD_PRELOAD, and wrap malloc inside your own function.

Solution 5

See our CheckPointer tool, which will check every pointer access for validity. Its not particularly fast, but it will catch errors that even Valgrind wont catch (e.g., pointers to deallocated stack frames, etc.)

Another answer to this question shows a case where doing pure memory range checking on pointer validity would fail to detect a problem. He's sort of right, in that if only have memory range addresses you can't reliably check that a reallocated block of store is misused. This is called a temporal error. By associating the allocation event with the memory block as well as the range, you can detect this. And Checkpointer does this, and will detect the error.

View more solutions

Comments

[log0]

Nice ! I didn't know linking with a library was not standard though ;)

[Admin]

@Ugo Arguably, linking with a library is not standard. But that aside, what is in libraries used by tools such as valgrind is definitely non-standard, which is why they are platform specific.

[matias]

@Neil Why would linking with a library not be standard ?

[Admin]

@matias Neither the C++ nor the C standard really describes such a thing - but that is off the point of this question.

[log0]

@matias Neither the C++ nor the C standard really describes breadth first search, which means it is arguably not standard.

[Chris Dodd]

@Ugo -- the library is not necessarily be available on every platform that supports C or C++, so its not "standard"

[Will]

if you're using valgrind, you don't check things are addressable you just let valgrind explode when you have a bug, and you fix it :)

[josesuero]

@Ugo: the standard describes the mechanisms used to implement a breadth first search. it does not describe the mechanisms used to implement library functionality. It describes how multiple translation units are turned into one program, but it doesn't describe any mechanism* by which separate libraries can be created, or loaded by your application.

[log0]

@Neil/jalf/Chris Well you are right linking is not standardized but you are still doing standard c++. Same thing with platform specific code, assigning the video frame buffer address somewhere in your code doesn't make your code non standard it just makes it platform specific.

[David Thornley]

@Ugo: I can easily write a breadth-first search algorithm in standard C++ (C would be a little more difficult, not having STL containers, std::deque in particular). valgrind is not necessarily available with a standard C++ platform, and cannot be written in standard C++. Therefore, in any standard C++ implementation I've got breadth-first search, but not necessarily valgrind.

[log0]

@David you mean std::queue don't you ?

[David Thornley]

@Ugo: I was thinking std::deque at the time, for some reason, but std::queue is a much better choice. Thanks.

[Mateusz Piotrowski]

could you please update the link to the AllocLen? It seams dead :/

[Will]

@MateuszPiotrowski Symbian is dead, and it seems now so is the documentation :(