SEH、访问冲突和堆栈保护页
我发布了一个关于验证指针可访问性的问题。 结论是要么使用 IsBadReadPtr 检查指针，要么使用 SEH 捕获异常（最好两者都不使用，并调试应用程序，但这不是这里的问题）。
IsBadReadPtr 被认为是不好的，因为除其他原因外，它会尝试读取指针，并会捕获任何异常。 它可能捕获堆栈保护页面异常，并且从而阻止它到达内存管理器，内存管理器应该扩大堆栈。
如果我使用 SEH 并仅捕获 EXCEPTION_ ACCESS_VIOLATION 异常，这会产生同样的问题吗？
另一件事：使用 SEH 有何影响？ 这篇文章建议“编译器不能在受 SEH 保护的代码中执行流分析”。 如果我在 __try 块内调用函数怎么样？ 编译器根本不会优化被调用的函数吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想会的。 解决方法可能是在开始调用 IsBadReadPtr 之前探测您知道和关心的任何线程的堆栈（通过“探测堆栈”我的意思是故意触及堆栈中的每个内存页，以确保每个页是预先分配的）。
如果函数不是内联的，我希望编译器应用通常的优化（函数的优化不会受到函数调用位置的影响）。
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).
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).