Is it safe to catch an access violation in this scenario?

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

Ok, inazaruk posted an answer that was heavily downvoted and then deleted suggesting the use of IsBadReadPtr + VirtualQuery (to avoid guard or no access pages.) Reading the links he posted alerted me to the fact that reading a random area of memory has worse potential side-effects than an access violation.

Accidentally accessing a guard page at the end of a thread stack, will cause the program to terminate abruptly if that thread stack grows.

Therefore catching the access violation is potentially unsafe. This answers the question.

Answer 2

I think it should be safe. But probably a bad idea.

However, if you need to mix pool-allocated memory with non pool allocated memory, I think you need to store information about that somewhere. Maybe every memory allocation made using pool_alloc() could have a tiny header, "hidden" before the actual allocation. This header could hold information about how it was allocated. So char *block = (char *)pool_alloc(32) would actually allocate 32+sizeof(BlockHeader) bytes. And block - sizeof(BlockHeader) would provide access to the header.

IsBadReadPtr is obsolete according to msdn:

Important This function is obsolete and should not be used. Despite its name, it does not guarantee that the pointer is valid or that the memory pointed to is safe to use. For more information, see Remarks on this page.

Answer 3

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.

Answer 4

You need a better test. There's no real guarantee that you will get an AV if malloc was used as the round-down point may have also been allocated to your application and thus your access to that memory will be allowed.