======================================================================== Comment expliquer ces différences entre SG 3.5 et SG svn ? $ ./loba platform.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD [Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data [Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data [Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data [Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data [Fafard 2579.229566] [comm/DEBUG] received LOAD: 366.211 from Bourassa [Fafard 2605.989948] [comm/DEBUG] received LOAD: 20.0806 from Bourassa [Fafard 2612.318155] [comm/DEBUG] received LOAD: 4.74548 from Bourassa [Fafard 2616.450666] [comm/DEBUG] received LOAD: 3.09753 from Bourassa $ ./loba-dev platform_dev.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD [Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data [Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data [Fafard 1519.035900] [comm/DEBUG] received LOAD: 366.211 from Bourassa [Fafard 1519.035900] [comm/DEBUG] send LOAD: 282.074 to Ginette_data [Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data [Fafard 1629.312931] [comm/DEBUG] received LOAD: 20.0806 from Bourassa [Fafard 1629.312931] [comm/DEBUG] received LOAD: 4.74548 from Bourassa [Fafard 1629.312931] [comm/DEBUG] send LOAD: 6.19507 to Ginette_data [Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data [Fafard 1898.705676] [comm/DEBUG] received LOAD: 3.09753 from Bourassa [Ginette 1932.076243] [comm/DEBUG] received LOAD: 282.074 from Fafard [Ginette 1940.343540] [comm/DEBUG] received LOAD: 6.19507 from Fafard Probablement par un bug dans SG 3.5. ======================================================================== Il semblerait qu'il y ait un bug dans SG 3.5, et qu'on ne puisse pas utiliser MSG_comm_waitany() pour l'émetteur *et* le récepteur sans risquer d'interblocage. Le problème devrait être contourné correctement depuis le commit cd6b253 Use MSG_comm_waitall for communicator::flush(true). ======================================================================== Avec SG 3.5, les communications doivent être détruites dès que possible avec MSG_comm_destroy(). Si ce n'est pas fait, la simulation peut être extrêmement ralentie. Le problème devrait être contourné correctement depuis le commit 404a8d5 Do not call flush automatically in communcator::send... ======================================================================== Valgrind détecte une fuite de mémoire liée à un appel à backtrace. Le problème semble être indépendant de SimGrid et peut être reproduit avec le code suivant (NB: l'équivalent, compilé avec gcc ne génère pas d'erreur). ,---- | #include | #include | int main() | { | void *buffer[64]; | int size = -1; | size = backtrace(buffer, sizeof buffer / sizeof buffer[0]); | std::cerr << "backtrace() returned " << size << "\n"; | } `---- ==532== HEAP SUMMARY: ==532== in use at exit: 56 bytes in 1 blocks ==532== ... ==532== LEAK SUMMARY: ==532== ... ==532== still reachable: 56 bytes in 1 blocks ========================================================================