我在我的C++应用程序中遇到了随机崩溃的问题，它可能一个月不会崩溃，但有时会在启动时立即崩溃，有时则在数小时后崩溃（或根本不崩溃），甚至有时在一小时内会崩溃10次。
我在GNU/Linux上使用GCC，在Windows上使用MingW，因此无法使用Visual Studio JIT Debug...
我不知道该如何继续下去，随意查找代码是行不通的，因为代码很庞大（而且很大一部分不是我写的），还包含一些旧的东西，而且我也不知道如何重现这个错误。
编辑：很多人提到了...我如何生成核心转储、小转储或其他转储？这是我第一次需要进行事后调试。
编辑2：实际上，DrMingw捕获了一个调用堆栈，没有内存信息...不幸的是，调用堆栈并没有对我有太大帮助，因为最后突然进入了一些没有调试信息的库（或其他内容），导致只显示了一些十六进制数字...所以我仍然需要某种有效的转储来提供更多信息（特别是关于造成“访问冲突”错误的位置中存在的内容...具体来说就是，在内存中的什么位置出现了问题）。
此外，我的应用程序使用Lua和Luabind，也许错误是由.lua脚本引起的，但我不知道如何对其进行调试。
试用Valgrind（它是免费的、开源的）：
Valgrind包含六个生产质量的工具：内存错误检测器、两个线程错误检测器、缓存和分支预测分析器、生成调用图的缓存分析器以及堆分析器。还包括两个实验性的工具：堆/栈/全局数组溢出检测器和SimPoint基本块向量生成器。它能运行在以下平台上：X86/Linux、AMD64/Linux、PPC32/Linux、PPC64/Linux和X86/Darwin(Mac OS X)。
该软件包中的Memcheck部分可能是开始使用的地方：
Memcheck是一种内存错误检测器。它可以检测以下C和C++程序中常见的问题。
访问不应访问的内存，例如超越和低于堆块界限，超越栈的顶部以及访问已被释放的内存。
使用未定义的值，即未初始化或来源于其他未定义值的值。
错误释放堆内存，如重复释放堆块或使用malloc/new/new[]与free/delete/delete[]不匹配。
在memcpy和相关函数中重叠src和dst指针。
内存泄漏。
首先，你很幸运，在短时间内多次出现进程崩溃。这应该使得处理过程更加容易。
以下是处理方法:
获取崩溃转储
首先，你真的需要获取崩溃转储。
如果程序崩溃时没有生成转储文件，那么请编写一个可靠地生成崩溃转储的测试用例。
重新编译带有调试符号的二进制文件或确保可以使用调试符号分析崩溃转储。
确定可能存在问题的函数
假设你已经获得了崩溃转储，请在gdb或你最喜欢的调试器中查看它，并记得显示所有线程！可能导致错误的线程不一定是你在gdb中看到的线程。
查看gdb报告的二进制文件崩溃位置，确定一些可能导致问题的函数。
查看多个崩溃并隔离出所有崩溃中常见的活动代码段，这样可节省时间。
加强状态检查
通常情况下，崩溃发生是因为某些不一致的状态。要继续进行，最好的方法通常是加强状态要求。具体步骤如下:
对于你认为可能导致问题的每个函数，请记录输入或对象在进入该函数时必须具有的合法状态。(同样适用于从函数退出时必须具有的合法状态，但这并不太重要)。
如果函数包含循环，请记录其每个循环迭代开始时需要具有的合法状态。
为所有此类合法状态表达式添加asserts断言。
重复
然后重复这个过程。如果它仍然在你的断言之外崩溃，请进一步加强断言。在某个时刻，处理将在断言上崩溃而不是因为某些随机崩溃。此时，您可以集中精力尝试弄清楚程序是如何从函数入口处的合法状态到达断言发生的非法状态的。
如果将断言与详细日志记录配对，则应更容易跟踪程序的操作。
在调试器下启动程序（我确定GCC和MingW会有一个调试器），等待它在调试器下崩溃。在崩溃点，您将能够看到哪个特定操作失败了，查看汇编代码、寄存器、内存状态 - 这通常有助于找到问题的原因。
在我工作的地方，程序崩溃通常会生成一个 core dump 文件，可以在 windbg 中进行加载。
然后我们会有程序崩溃时内存的图像。虽然你并不能做太多事情，但至少它能给你最后一个调用栈。一旦你知道了导致崩溃的函数，你就可以追踪问题，或者至少可以将问题减少到更可重现的测试用例。
听起来你的程序可能受到了内存损坏的影响。如前所述，Linux上最好的选择可能是使用valgrind。但以下还有两个选项：
首先使用调试malloc。几乎所有的C库都提供了一个调试malloc实现，它可以初始化内存（普通的malloc会在内存中保留“旧”的内容），检查分配块的边界是否损坏等等。如果这还不够，也有很多第三方实现可供选择。
你可能想看一下VMWare Workstation。我没有这样设置过，但从他们的营销材料中得知，他们支持一种非常有趣的调试方式：在“记录”虚拟机中运行调试程序。当内存损坏发生时，在受损地址处设置一个内存断点，然后在VM中回溯到恰好覆盖那块内存的那一刻。请参阅此PDF文档，了解如何在Linux/gdb中设置重放调试。我相信Workstation 7有15或30天的试用期，这可能足以从你的代码中找出这些错误。
对于Windows：有一个适用于mingw的JIT调试器，称为DrMingw：
valgrind运行应用程序，以查找内存错误。随机崩溃通常是由于破坏内存引起的。ulimit -a），然后当它崩溃时，您将能够通过gdb找到崩溃位置。valgrind 或其他一些内存检查器是我能建议的最好的东西了。否则，你几乎必须重写整个应用程序。 - Douglas Leeder听起来像是类似于竞态条件的棘手问题。
我建议您创建一个调试版本并使用它。您还应确保程序崩溃时创建了核心转储。
下次程序崩溃时，您可以在核心转储上启动gdb，并查看问题所在。这可能是一个连续的故障，但这应该能帮助您入门。