我在键入此问题时在GDB内捕获了罕见的程序崩溃。不幸的是，所有的工程师都可能能够帮助我弄清楚为什么发生崩溃目前正在睡觉。
崩溃的程序恰好是铬
如果generate-core-file捕获所有内容 gdb现在就知道"实时"崩溃的铬过程，我将能够清理崩溃的实例，重新启动等，这将是非常不错。
但是，如果有任何东西 generate-core-file错过了，我绝对不想使用它。
我应该好吗？
这是在32位Linux上（Slackware）。
fwiw，我认为该错误与线程管理有关 - 崩溃本身以> 700 pthread_create: Resource temporarily unavailable消息开头，然后，内存管理器无法分配8MB RAM，即使我现在有223倍的223倍，并且很多最重要的是未使用交换的GB，因此这可能是许多线程之间的竞赛条件。
但是，如果完全有任何产生核心文件的错过的东西，我绝对不想使用它。
肯定是现场GDB会话中core不可能的事情。这样的东西集很小，但不是空的。
如果您非常关心这种特殊的崩溃，则应使用generate-core，然后使用等待让工程师告诉您她是否在乎实时会议。