调试来自相同代码库的运行时差异

我目前使用VEINS库和仿真软件包来做一些实验。由于这些游戏运行时间很长，我试图使用大学集群服务器（KITE 2.0/RHEL6.6/Lustre 2.5.29.ddnpf3） - 但是，现在我遇到了几个不同的运行时错误，相同的代码在我的本地机器上运行得非常好（Fedora 23）。我正在寻找一种轻松调试此问题的方法。我怀疑原因在于不同的gcc版本，或者是其他一些我无法远程更改的系统级库（但我不确定）。我确定OMNeT ++版本是一样的; VEINS库由我提供，本地和远程都是相同的。调试来自相同代码库的运行时差异

我所遇到的问题的一个例子是discussed here，我最终固定like this（据我所知，这两个版本具有相同的语义... DimensionSet延伸std::set，并DimensionSet::timeFreqDomain是(Dimension::time, Dimension::frequency)初始化static const如在修复中）。

寻找原因的好方法是什么？有没有一种简单的方法来在这些机器之间“交叉编译”，或者通过某种方式来区分二进制文件以查找原因？我在哪里寻找处理这些问题的常见方法？

来源

2016-03-04 Rens van der Heijden

这听起来像是一个内存初始化问题，成功的案例很幸运。也许一个变量需要为零，恰好在“好”的机器上，但不会发生在失败的机器上。 – donjuedo

在我描述的问题中，'Dimension :: time'和'Dimension :: freq'被初始化为相同的值（至少在GDB中运行时），并且由于某些原因，该集合缺少元素。我更感兴趣的方法来发现这些问题，而不是找出这个特定错误的来源，但感谢反馈:-)。 –

事实上，确实存在一些与内存有关的问题！出于某种原因，“Dimension :: time”和“Dimension :: frequency”具有相同的“唯一”标识符。我仍然在追查为什么发生这种情况，因为有代码可以获取未使用的ID。这可能与该问题的并行访问有关（尽管我认为所有内容都是线程安全的）。 –

我可能已将错误追踪到static initialization order fiasco的示例：MiXiM的Dimension::time是一个静态成员，因此它不应该用于初始化其他静态成员。不幸的是，这正是MiXiM（以及Veins推广的）所导致的崩溃。

我已经推commit 7807f47c（静脉4.4的一部分），它摆脱了几乎所有的静态成员，所以整个框架应该是更安全的使用。

来源

2016-03-17 08:51:00

谢谢！这听起来完全像我发现的问题。我最大的问题是，我不知道什么是“正确”的解决方法。 –

调试来自相同代码库的运行时差异

回答

相关问题