tags:

views:

390

answers:

1

I've posted a question about validating a pointer's accessibility. The conclusion was either to use IsBadReadPtr to check the pointer, or SEH to catch the exception (and preferably to use neither, and debug the application, but that's not the issue here).

IsBadReadPtr is said to be bad because, among other reasons, it would try to read the pointer, and would catch any exception. It might catch a stack guard page exception, and thus prevent it from reaching the memory manager, which should have enlarged the stack.

If I use SEH and catch only EXCEPTION_ ACCESS_VIOLATION exceptions, would this create the same problem?

Another thing: What are the implications of using SEH? This article suggests that "the compiler can’t perform flow analysis in code protected by SEH". How about if I call a function inside __try block. Would the compiler not optimize the called function at all?

+1  A: 

If I use SEH and catch only EXCEPTION_ ACCESS_VIOLATION exceptions, would this create the same problem?

I think it would. A workaround might be to probe the stack[s] of any thread[s] you know and care about, before you start calling IsBadReadPtr (by "probe the stack" I mean to deliberately touch every memory page in the stack, to ensure every page is pre-allocated).

Would the compiler not optimize the called function at all?

If the function is not inlined, I would expect the compiler to apply the usual optimizations (optimization of the function wouldn't be affected by where the function is called from).

ChrisW
Could you make sure that the stack on the threads you cared about were completely allocated by calling CreateThread with the committed and reserved values the same? Also, setting the image thread stack settings to match. It wouldn't work for threads created by libraries, though.
Chris Smith