为什么我的代码不会在Windows 7上出现段错误?

Tre*_*vor 14 c++ odbc segmentation-fault windows-7

这是一个不寻常的问题,但这里有:

在我的代码中,我意外地在某处取消引用NULL.但是,不是使用segfault崩溃的应用程序,它似乎停止执行当前函数并将控制权返回给UI.这使调试变得困难,因为我通常希望收到崩溃警报,以便我可以附加调试器.

可能是什么导致了这个?

具体来说,我的代码是ODBC驱动程序(即DLL).我的测试应用程序是ODBC测试(odbct32w.exe),它允许我在我的DLL中显式调用ODBC API函数.当我调用其中一个具有已知段错误的函数时,ODBC测试只是将控制权返回给UI而不打印函数调用的结果.然后我可以再次调用我的驱动程序中的任何函数.

我确实知道技术上应用程序调用ODBC驱动程序管理器,它加载并调用我的驱动程序中的函数.但是,由于我的段错误(或正在发生的任何事情)导致驱动程序管理器功能也不返回(由应用程序不打印结果证明),这就是重点.

我的一个有类似机器的同事遇到了同样的问题而另一个没有,但是我们无法确定任何具体的差异.

asv*_*kau 42

Windows具有非可移植语言扩展(称为"SEH"),允许您将页面错误和分段违规作为异常进行捕获.

有些部分的OS库(特别是在OS代码中处理一些窗口消息,如果我没记错的话)有一个__try块,并且即使面对这样的灾难性错误,也会使你的代码继续运行.可能你被称为其中一个__try块.伤心但真实.

查看此博客文章,例如:消失的OnLoad异常的情况 - x64中的用户模式回调异常

更新:

我发现在评论中归因于我的那种想法有点奇怪.作为记录:

  • 我并没有声称自己SEH是坏的.

    我说这是"非便携式",这是事实.我还声称STATUS_ACCESS_VIOLATION在用户模式代码中使用SEH忽略是"悲伤".我支持这个.我希望我有勇气在新代码中执行此操作,并且您正在查看我会对我大喊大叫的代码,就像我写的那样catch (...) { /* Ignore this! */ }.这是个坏主意.这对于访问冲突尤其不利,因为获取AV通常意味着您的进程处于错误状态,并且您不应该继续执行.

  • 并不认为SEH的存在意味着你必须吞下所有的错误.

    当然,SEH是一种通用机制,并不是每次愚蠢使用它的原因.我所说的是一些Windows二进制文件STATUS_ACCESS_VIOLATION在调用函数指针时吞下,这是一个真实且可观察的事实,并且这不是很漂亮.请注意,他们可能有历史原因或情有可原的情况来证明这一点.因此"悲伤而真实".

  • 我并没有在这里注入任何"Windows与Unix的"豪言壮语.在任何平台上,一个坏主意都是个坏主意.尝试从SIGSEGVUnix类型的操作系统恢复也同样粗略.

  • 我不会将SEH称为语言扩展,我将其视为操作系统提供的服务.我不太确定窗口消息回调 - 它们是什么?你的意思是WNDPROCs?虽然Windows与UNIX不同,但仅凭这一事实并不能使它低劣. (2认同)

Gen*_*yev 18

解除引用NULL指针是一种未定义的行为,它几乎可以产生任何东西 - 一个seg.fault,一个写入IRS的信,或一个发布到stackoverflow :)

  • 这是坏的升序吗?:) (11认同)
  • 这是100%正确 - 但不是这个具体问题的答案. (3认同)