在Delphi中保护页面异常？ [英] Guard page exceptions in Delphi?

问题描述

有一个Raymond Chen的帖子，其中他告诉IsBadXxxPtr功能有多糟糕的是通过吃防护页面异常。

我不太明白它如何应用于Delphi。谁应该怎么通常（即不调用IsBadXxxPtr）处理这个异常？
我知道Delphi插入了一个代码，例如访问大型静态数组的内存，正是由于这个原因：扩展堆栈。

但是如果提出了防护页异常：谁将在Delphi应用程序中处理它？不能不小心使用try /除了不适当的方式混乱吗？ Delphi的调试器会通知我有关这些异常？

解决方案

Windows结构化异常处理（SEH）具有两阶段结构。当发生异常时，Windows首先通过遵循注册的异常处理程序链（其头部存储在x86上的fs：[0]中，即FS段指向的段中的第一个双字）来查找异常的处理程序注册 - 所有这些丑陋的16位段偏移逻辑在32位没有消失，它只是变得不那么相关）。

搜索是通过调用具有特定标志的功能，指向堆栈中每个异常帧中的指针。 fs：[0]指向最上面的框架。每帧指向前一帧。最终，列表中的最后一帧是由操作系统提供的（该处理程序将在未处理的异常到达时弹出一个应用程序崩溃对话框）。

这些函数通常检查异常的类型，并返回一个代码来指示该做什么。其中一个可以返回的代码基本上是忽略这个异常并继续。如果Windows看到这一点，它将将指令指针重置为异常点并恢复执行。另一个代码表示这个异常帧应该处理给定的异常。第三个代码是我不会抓住这个异常，继续搜索。 Windows继续调用这些异常过滤器函数，直到找到一个处理例外情况的方法。

如果Windows找到通过捕获异常来处理异常的那个，那么它将继续将堆栈解压缩回该处理程序，其中包括再次调用所有函数，只传递不同的标志。在这一点上，函数执行 finally 逻辑，直到执行除了逻辑的处理程序。 p>

但是，使用堆栈页面保护异常，过程是不同的。语言的异常处理程序都不会选择处理这个异常，因为否则堆栈生成机制会中断。相反，过滤器搜索将一直过滤到由OS提供的基本异常处理程序，该异常处理程序通过提交适当的内存来增加堆栈分配，然后返回适当的返回码，以指示操作系统应该继续停留，而不是放松堆栈。

工具和调试基础设施旨在让这些特殊的异常正常播放，所以你不需要担心处理它们。 / p>

您可以在。

There is a post by Raymond Chen, where he tells how bad IsBadXxxPtr function is by eating guard page exception.

I don't quite understand how it is applied to Delphi. Who and how should normally (i.e. without call to IsBadXxxPtr) process this exception? I do know that Delphi inserts a code, which (for example) access a memory for large static arrays - exactly for this reason: to expand stack.

But if guard page exception is raised: who will handle it in a Delphi application? Can't I accidentally mess with it by using try/except in inappropriate way? Will Delphi's debugger notify me about these exceptions?

解决方案

Windows structured exception handling (SEH) is has a two-phase structure. When an exception occurs, Windows first looks for a handler for the exception by following the registered exception handler chain (the head of which is stored in fs:[0] on x86, i.e. the first dword in the segment pointed to by the FS segment register - all that ugly 16-bit segment-offset logic didn't go away in 32-bit, it just became less relevant).

The search is done by calling a function with a particular flag, a pointer to which is stored in each exception frame on the stack. fs:[0] points to the topmost frame. Each frame points to the previous frame. Ultimately, the last frame on the list is one that has been provided by the OS (this handler will pop up a app-crash dialog if an unhandled exception reaches it).

These functions normally check the type of the exception, and return a code to indicate what to do. One of the codes that can be returned is basically, "ignore this exception and continue". If Windows sees this, it will reset the instruction pointer to the point of the exception and resume execution. Another code indicates that this exception frame should handle the given exception. A third code is "I'm not going to catch this exception, keep searching". Windows keeps on calling these exception filter functions until it finds one that handles the exception one way or the other.

If Windows finds one that handles the exception by catching it, then it will proceed to unwind the stack back to that handler, which consists of calling all the functions again, only passing in a different flag. It's at this point that the functions execute the finally logic, up until the handler which executes the except logic.

However, with the stack page guard exception, the process is different. None of the language's exception handlers will elect to handle this exception, because otherwise the stack growth mechanism would break. Instead, the filter search filters all the way through to the base exception handler provided by the OS, which grows the stack allocation by committing the appropriate memory, and then returns the appropriate return code to indicate that the OS should continue where it left off, rather than unwind the stack.

The tool and debugging infrastructure are designed to let these particular exceptions play out correctly, so you don't need to worry about handling them.

You can read more about SEH in Matt Pietrek's excellent article in MSJ from over a decade ago.

这篇关于在Delphi中保护页面异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！