Figuring out if address is in heap or stack

I'm trying to code something that will print an error statement if the user tries to free something never malloc-ed (like if they try to free the address of a local variable declared on the stack).

I'm not quite sure how to approach this other than to try to check if the address of the variable attempted to be freed is in the stack (or check if the address of the variable attempted to be freed is NOT in the heap) -- however, this is difficult because I don't know what memory addresses would separate teh stack from the heap and how to go about finding that out. Any advice?

Thank you!

Not all implementations make a distinction between heap, stack, and other areas of memory, so you can't just rely on checking the value of a pointer is in some range.

Generally speaking, you would need to find some way to track all pointers that are returned by malloc()/calloc()/realloc(). Then all you need to do is check if a supplied pointer is one of the tracked values, and issue an error message.

To do that, there are two possible approaches.

1) Dig into compiler/library specific data structures maintained internally by malloc()/calloc()/realloc()/free() - or the system calls that they use. One problem with this approach is that it is highly specific to the implementation (compiler and standard library). The main problem is that the implementation of malloc()/calloc()/realloc()/free() is often not documented, so you would be relying on reverse engineering or guesswork.

2) Write your own wrappers for malloc()/calloc()/realloc()/free() that call the originals, but that keep track of all allocations and deallocations. The problem with this is that it requires your programs to use your wrappers, rather than calling malloc()/calloc()/realloc()/free() directly, otherwise the tracking will be incorrect (false negatives and false positives).

Bear in mind that the NULL pointer is special to free() and realloc().


Personally, I consider it is better to be disciplined enough in your usage of malloc()/calloc()/realloc()/free() so you avoid such problems. It's easier to avoid a problem than try to detect its symptoms. Sadly, people often prefer to hack or grow their programs organically and don't think about avoiding problems until they encounter effects of a hard-to-find flaw in the their program.

There are tools like valgrind - a suite of tools for debugging and profiling, which can detect/report memory management problems.

Overall your idea is quite pointless since this is not a common error. It's essentially a logic error and you simply cannot protect against logic errors in general.

However:

In Linux, for example, the ultimate heap allocator is sbrk(). All it does is extend the data segment, which begins at a some address and grows upwards. All allocations will be greater than or equal to this starting address. On the other hand, the stack starts at the "top" of memory and grows downwards towards the current end of the heap.

So it would be very easy to tell if something is on the stack or not. You'd simply test whether the address is greater than the address of the last variable added to the stack.

But that's not enough since statically allocated variables (such as globals) are not on the stack but are instead below the bottom of the heap. To detect them you could do an initial malloc and store that address as the bottom of the heap.

Code:

---

void *bottom_of_heap;

void mymalloc_init(void)
{
    bottom_of_heap = malloc(sizeof(int));
}

void myfree(void *ptr)
{
    int bottom_of_stack;
    if (ptr > &bottom_of_stack || ptr < bottom_of_heap) {
        fprintf(stderr, "Attempt to free non-heap memory.\n");
        exit(THIS_GUYS_NUTS);
    }
    free(ptr);
}

---

I haven't tested it or even thought about it that much but I believe that something like that would work on Linux. It may even work on Windows. Any solution would be implementation specific, though.

For windows 32 bit console programs created by microsoft compilers the order is: stack, heap, statics (program image), heap, where some of the heap is before statics and some is after. Note that these are virtual addresses that make a virtual continuous address space out of scattered physical memory pages. Small allocations are usually in the heap before the statics, large allocations (2 MB or more) after the statics.

Quote:

---

Originally Posted by rcgldr

For windows 32 bit console programs created by microsoft compilers the order is: stack, heap, statics (program image), heap, where some of the heap is before statics and some is after. Note that these are virtual addresses that make a virtual continuous address space out of scattered physical memory pages. Small allocations are usually in the heap before the statics, large allocations (2 MB or more) after the statics.

---

What's you souce on that?
Here's a diagram that doesn't fit that model:
http://www.cs.uleth.ca/~holzmann/C/s...morylayout.gif

@rcgldr, Still waiting for that source.

Quote:

---

Originally Posted by rcgldr

For windows 32 bit console programs created by microsoft compilers the order is: stack, heap, statics (program image), heap, where some of the heap is before statics and some is after. Note that these are virtual addresses that make a virtual continuous address space out of scattered physical memory pages. Small allocations are usually in the heap before the statics, large allocations (2 MB or more) after the statics.

---

Quote:

---

Originally Posted by oogabooga

What's you source on that?

---

I wrote a program that displays the addresses of static, stack based, and heap based variables, compiled with Visual C / C++ 4.0, and with Visual Studio 2005, running on Windows XP 32 bit. The results were similar. For a small program, the stack goes from 30000 hex to 12FFFF hex (1MB), first heap segment between stack and program image, usually around 330000 hex, statics between 400000 hex and 401000 hex, program code base at 401000 hex, and second heap segment after program image, from 40A000 hex to 7C800000 hex (where kernel.dll and other os stuff is mapped). The virtual address ranges for the heap segments are just "reserved", and not valid until malloc or new are used. These addresses would change for a large program or one compiled to have a large stack. There are debuggers and/or trainers for windows that can display the memory map for a process.

Very interesting! Thanks for the info.

Note that Windows Vista and later version randomize the memory map addresses somewhat to reduce the chance of buffer overflow viruses from working.

Address space layout randomization - Wikipedia, the free encyclopedia

I would say that grumpy's original idea would be best.

C doesn't specify that a stack must exist -- there could be no stack at all.

However, if there is a stack, then it must exist somewhere between &argc (the first parameter to main()) and wherever the top of the stack happens to be -- assuming standard calling conventions, you could do something like this:

Code:

---

void* TopOfStack;

int main(int argc, char **argv)
{
    TopOfStack = &argc;
}

int IsAddressOnTheStack(void* addr)
{
    return addr >= &addr && addr <= TopOfStack;
}

---

EDIT: I still think it's a bad idea. There are situations where this won't work, such as in a thread (each thread has a different stack).