Question

I’ve read a lot, including here on SO that suggests this is a very bad idea in general and that the only thing you can do safely is exit the program. I’m not sure that this is true.

This is for a pooling memory allocator that hands off large allocations to malloc. During pool_free() a pointer needs to be checked it it belongs to a pool or was allocated with malloc. By rounding the address down to the nearest 1MB boundary, I get a pointer to the beginning of a block of memory in the pool, or undefined if malloc was used. In the first case I can easily verify that the block of memory belongs to the pool, but, if it does not I will either fail this verification, OR I will get an access violation (note that this is a read-only process). Could I not catch this with SEH (Windows) or handle the signal (POSIX) and simply treat it as a failed verification? (i.e. this is only possible if malloc was used, so pass the ptr to free())

Edit: People seem to be missing the OR above. I do not expect to get an access violation if the pointer was allocated with malloc, but it is one possible outcome. The procedure using the pointer to the beginning of the block (at the 1MB boundary) is to verify a magic number, then follow a pointer to the memory pool, and check that it actually contains aforementioned pointer to the block. If any of these read-only steps produces an access violation, it fails validation as surely as if any individual step failed.

Answer 1

There is no need to implement a reactive mechanism. You can get in front of the problem by aligning heap allocations to a 1 MB boundary:

1. Windows: _aligned_malloc(size, 1<<20)
2. Unix: memalign(1<<20, size)

Using this approach, rounding down to 1 MB is guaranteed to point into an allocated block of memory, and you simply have to discern whether that address is in the pool or outside it (in which case it was obviously malloced).

You need to be cautious that you only use aligned heap allocation for genuinely large objects. If you use it for, say, size > 100 kB, the allocator will leave huge gaps between objects. Ideally, only use it for objects that don’t fit in a 1 MB pool block.