Delphi try/最终导致异常

向外部C/C++库调用一个方法，该库返回指向Delphi XE6应用程序的指针。然后有一个try/finally块，在finally块中，由C/C++库分配的内存被释放。如果我在最后释放内存，我将免费获得一个特权指令异常。如果我将内存释放到try/finally块之外，则没有例外

// This crashes
ptr := CMethod();

try
  // 
finally
  freeCPtr (ptr);
end

// This doesn't crash
ptr := CMethod();
freeCPtr (ptr)

请注意，freeCPtr是一个由C库导出的方法，用于释放CMethod返回的指针。两个独立的第三方开发人员已经证明，CMethod和freeCPtr在C应用程序中可以正常工作。我很想知道为什么使用try/finally可能会导致异常

---

更新结果表明，原始C/C++库的作者已将其调用约定从stdcall更改为cdecl。通常，当有问题时，我首先检查调用约定，但是我知道以前的代码我工作得很好，所以最初没有考虑检查调用约定。这个故事的寓意是，每当一个人在调用外部库时出现异常行为时，请检查：1调用约定是否兼容；2您正在将正确的类型传递给外部库

很难看出问题出在哪里，但根据我的经验，像这样的无法解释的问题，在一个版本中有效，而在另一个版本中无效，尤其是在调用外部C/C++.dll:s时，当优化设置为on时会出现

确保在您使用的项目设置或配置文件中未将“优化”设置为“开”，然后查看这是否有任何不同。当然，在单元本身中使用{$Optimization Off}也可以工作

---

我意识到这可能更多的是一个评论而不是一个答案，但我是一个如此的新手，以至于我没有那么多的观点-

我应该澄清一下，freeptr函数是由C库导出的。我将更新问题以反映这一点。啊，好吧，这样更好。我认为这是Delphi端的一个函数；-。freeCPtr会从C端抛出异常吗？我能想到的唯一一件事是，在C端，释放和分配一些微妙的错误会有问题？这在某些情况下表现出来。例如，用C++新操作符分配内存并用Delphi来自由释放，而不是删除delphi，我使用与以前相同的调用约定，STDCALL。我刚刚在XE上试过，但也失败了，这对我来说是个新闻。因此，我认为C/C++方面发生了一些变化，可能是调用约定的变化。在这个阶段，我不认为这是德尔福错误，我想知道。我会进一步调查。我试过了，简短的回答是否定的。取而代之的是，我决定采纳别人给我的一些建议，拍摄新闻并编写一个小的c/c++dll来测试这个问题。这很有效。然后我开始怀疑原始代码的作者是否改变了什么。原来，以前的开发人员在没有告诉任何人的情况下更改了调用约定。最后，通过在我这边将stdcal更改为cdecl，问题得到了解决！哦，真烦人。好吧，很高兴听到它成功了。如果你愿意，你可以在你的问题中添加一个更新的解决方案或答案，这样其他人就不必阅读所有这些评论就能得到答案。