X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/loba.git/blobdiff_plain/5a4a8663668a3af89fe7c4026d08f3e0fb144f05..b4d90a50ce65a5efb75c0a28b269120ea51d57cf:/BUGS

diff --git a/BUGS b/BUGS
index ff54efc..464e620 100644
--- a/BUGS
+++ b/BUGS
@@ -1,3 +1,104 @@
-./loba cluster1000.xml -N64 -L100 -i100 -a fair -T hcube
-=> leads to deadlock (with stable)
+========================================================================
+Les fonctions MSG_get_host{number,table} n'existent plus dans les
+dernières versions de SimGrid.  Utiliser MSG_hosts_as_dynar à la place.
 
+========================================================================
+Les exécutions parallèles donnent des résultats différents.
+Pourquoi ?
+
+========================================================================
+Les variables globales process::total_load_* ne sont pas protégées
+contre les accès concurrents.  Il n'est donc pas possible actuellement
+d'exécuter les simulations en parallèle (--cfg=contexts/nthreads).
+
+Corrigé en partie.  Il reste quelques "fixme: get locked?" à régler
+(ou pas).
+
+========================================================================
+##### RESOLVED BUGS COME AFTER THIS ####################################
+========================================================================
+Il faut réviser l'utilisation du mutex entre le thread d'équilibrage
+et le thread de calcul.  Il semble gardé beaucoup trop longtemps.
+
+Bon, une partie du problème est rectifiée par le commit
+48de954 Stop locking the mutex on data_receive.
+
+Pour le reste, je pense maintenant que ça ne gêne pas, au moins dans
+le simulateur.  Pour faire bien, il faudrait plus séparer les deux
+threads d'équilibrage et de calcul, et faire en sorte que chacun garde
+un cache des données globales partagées.  Il suffirait alors de
+synchroniser ces caches à chaque itération.
+
+Les données partagées sont essentiellement les données des voisins :
+load, to_send et debt.
+
+========================================================================
+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 <execinfo.h>
+| #include <iostream>
+| 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
+
+========================================================================