Fix message::to_string().

[loba.git] / BUGS

diff --git a/BUGS b/BUGS
index b1cc865db3ea925fcf8f4a610153f738a165864e..3a1a2a449398146b2e6d1347ca18aa9548c5c719 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1,3 +1,33 @@
+========================================================================
+En mode entier (-Z), aucune vérification n'est faite sur la charge
+totale, ni sur la répartition initiale!
+
+Il faut vérifier, et arrondir et émettre un warning dans le cas contraire :
+- que la charge totale est entière, dans main.cpp ;
+- au début de chaque process que la charge initiale est entière.
+
+Il faut également s'assurer que la répartition aléatoire produit une
+distribution entière.
+
+========================================================================
+##### 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
 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


@@ -24,6 +54,8 @@ $ ./loba-dev platform_dev.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&
 [Ginette 1932.076243] [comm/DEBUG] received LOAD: 282.074 from Fafard
 [Ginette 1940.343540] [comm/DEBUG] received LOAD: 6.19507 from Fafard
 
 [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
 ========================================================================
 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


@@ -41,3 +73,27 @@ Le problème devrait être contourné correctement depuis le commit
 404a8d5 Do not call flush automatically in communcator::send...
 
 ========================================================================
 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
+
+========================================================================