问RNG崩溃的c++程序

EN

以下是一些关于如何缩小问题来源的评论和想法：

• 几乎可以肯定的是，不是srand()或rand()函数导致崩溃/锁定。有可能是一个或多个随机数的组合让你的引擎进入了一个坏事情发生的状态。
• 第一步应该是重复这个问题，这样它总是在时间/地点发生。尝试使用像srand(12345)这样的常量种子，而不是使用srand(NULL)。根据您的引擎使用的其他因素(如用户输入)，这可能足以使它每次在同一地点崩溃。
• 如果使用调试器有问题(这是可疑的，可能是缓冲区溢出正在破坏堆栈)，请使用久经考验的方法将消息输出到文本日志文件。我建议输出生成的所有随机数，也许您会看到它崩溃时的模式(即，每当生成"42“时，它就会崩溃)。另一种选择是开始在各种函数中添加一些日志消息(从游戏更新循环等高级函数开始)。崩溃后，检查日志并开始添加更多日志消息，直到将其缩小到一行/函数。这不像使用调试器那么快，但有时是一个更好的选择，特别是如果你不知道从哪里开始looking.
• Once，你可以可靠地复制崩溃，开始删除东西，直到崩溃点改变或消失。这可能涉及到#ifdef、注释掉代码、设置应用程序选项，甚至创建项目的临时副本，这样您就可以简单地删除代码、编译和测试。这可能是困难的，如果项目是large/complex.
• More的类型的“崩溃”的信息将是有帮助的。通常情况下，程序不只是一般地崩溃，而是有特定的异常发生，锁定，等等。异常详细信息可以帮助您通过一些努力缩小问题的来源。

函数rand()不是可重入的，也不是线程安全的，因为它使用的隐藏状态在每次调用时都会被修改。这可能只是下一次调用要使用的种子值，也可能是更复杂的东西。为了在线程化应用程序中获得可重现的行为，必须显式设置此状态。函数rand_r()提供了一个指向无符号整数的指针，用作状态。这是一个非常小的状态，所以这个函数将是一个弱的伪随机生成器。尝试使用drand48_r(3)。

尝试在调试器下运行它

$ gdb myprog
(gdb) break main
(gdb) run
(gdb) record

例如：

(gdb) break abort
(gdb) break exit

因为它是c++：

(gdb) catch throw
(gdb) catch exception

最后(gdb)继续

当它停止时，反向继续，直到你找到罪魁祸首。

选项2：

valgrind --tool=massif --massif-out-file="massif.out.%p" myprog
ms_print massif.out.*

要检查堆分析，请执行以下操作。您不是不可能有内存泄漏