core dump python_什么是"Core Dumps",为什么"Haskell"可以没有?

Core Dump通常是操作系统提供的调试辅助操作。用于当程序崩溃——通常是不得不调用abort()——时将程序当时的内存快照保留在一个文件里。程序员可以用调试器分析其中的内容从而推断究竟是什么原因引起了崩溃。Windows和传统UNIX都提供了这样的选项，允许程序崩溃时内核自动介入并创建dump。通常内核和用户态程序都可以保存dump。

传统上C/C++程序很多错误都能造成程序崩溃，一个常见的例子是内存访问违例，不只是空指针，也包括很多其他的情形。对Windows而言，它也允许通过AppVerifier和Gflags强制在更多的情况让程序崩溃，比如内存泄漏或不当访问(野指针)时。Linux下我一般只用log，用工具调试的经验不多，如有专家不妨赐教。

Dump这东西往往很讨人厌，因为它只是程序崩溃瞬间的快照，而很多程序错误并不是出错即停的，从这个快照里推导出程序的bug，就像福尔摩斯要从凶杀现场还原出沼地蝰蛇如何爬到隔壁咬死受害人的过程，充满了谜题、猜测和推理，而且破案的成功率也难以保证。我幸运地有过两次成功地从dump分析bug的经历，每次分析几乎都历时一月以上。整体上在过去五年里，我遇到的情况都是以分析失败居多。相对地，我所合作过的程序员往往也不愿意调试这样的bug。

最近十年来由于托管程序兴起(Java/.NET/Python/...)，我们的实际程序生活中已经很少出现程序崩溃的情形了，取而代之的是以程序抛出异常的形式退出。这种情况下由于其运行时并无调用abort()之虞，程序往往不会有dump产生，因为操作系统并不负责管理那些异常，在它的角度上看它只能看到运行时系统(比如Python解释器或Java虚拟机)给出了某个非0的退出码然后退出执行。

这其中比较特别一点的是.NET。我曾经听说过Windows下可以通过Visual Studio在.NET程序抛出异常时强制介入并断下程序执行，然后程序员可以选择是否保存dump。因为.NET和Windows系统的紧密关系，微软可以做到这一点。而如果某个解释执行的程序能让解释器崩溃，那么问题可大了：这说明这个解释器可能被黑客作为攻击的目标。

至于写下那篇FAQ的那位“圣哲”所言的Strong Typing means no core dumps，又是一条梦呓一般的宣传。这根本是风马牛不相及的两个东西。没有core dump的充分条件是我们的程序运行在某个运行时之上，而当程序出错时运行时能正确处理错误而没有abort()，通常也就没有core dump。我接触Haskell的时间虽然很短，但至少也知道GHC和Hugs98都有解释执行的能力，GHC虽然可以编译代码，但它的程序也有一个厚厚的运行时。这才是Haskell没有core dump的真正原因。

=====

最后个人吐槽。话比较难听。如有喜爱Haskell的知友不适，请见谅。

对于能在Haskell社区的公开场合看到这样毫无常识的发言，我一点都不意外。就我开始接触Haskell以来，这也不是第一次遇到了。它完全符合我对Haskell社区一部分吹鼓手的印象：对形式逻辑毫无理性的迷恋和对计算机工程和历史非一般的无知，并且以一知半解为荣。最要命的是，恰恰是这帮迷恋逻辑和推理的人，说起话来毫无逻辑。

我想，恐怕这位FAQ作者所见过的最牛的所谓程序bug大概也就是编译错误。这样很好，就像我之前无数次说的，就让他们继续做他们的千秋大梦吧。