調試來自相同代碼庫的運行時差異

我目前使用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

謝謝！這聽起來完全像我發現的問題。我最大的問題是，我不知道什麼是「正確」的解決方法。 –

調試來自相同代碼庫的運行時差異

回答

相關問題