BUGS: add missing dates.

diff --git a/BUGS b/BUGS
index 464e6208f92a18334ce418fda40aef4a8e8974d8..1f5ee7e1c423010400babd5e7ad2438912669f2b 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1,25 +1,37 @@
 ========================================================================
 ========================================================================

+-- Wed, Feb 29 16:31:56 2012 +0100
+

 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 fonctions MSG_get_host{number,table} n'existent plus dans les
 dernières versions de SimGrid.  Utiliser MSG_hosts_as_dynar à la place.
 
 ========================================================================

+-- Wed, Feb 29 16:16:45 2012 +0100
+

 Les exécutions parallèles donnent des résultats différents.
 Pourquoi ?
 
 ========================================================================
 Les exécutions parallèles donnent des résultats différents.
 Pourquoi ?
 
 ========================================================================

+##### MOSTLY RESOLVED BUGS COME AFTER THIS #############################
+========================================================================
+-- Mon, Feb 27 13:26:08 2012 +0100
+

 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).
 
 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).
 

+-- Wed, Feb 29 15:54:31 2012 +0100
+

 Corrigé en partie.  Il reste quelques "fixme: get locked?" à régler
 (ou pas).
 
 ========================================================================
 Corrigé en partie.  Il reste quelques "fixme: get locked?" à régler
 (ou pas).
 
 ========================================================================

-##### RESOLVED BUGS COME AFTER THIS ####################################
-========================================================================
+-- Fri, May 20 17:01:33 2011 +0200
+

 Il faut réviser l'utilisation du mutex entre le thread d'équilibrage
 et le thread de calcul.  Il semble gardé beaucoup trop longtemps.
 
 Il faut réviser l'utilisation du mutex entre le thread d'équilibrage
 et le thread de calcul.  Il semble gardé beaucoup trop longtemps.
 

+-- Tue, May 24 14:55:59 2011 +0200
+

 Bon, une partie du problème est rectifiée par le commit
 48de954 Stop locking the mutex on data_receive.
 
 Bon, une partie du problème est rectifiée par le commit
 48de954 Stop locking the mutex on data_receive.
 


@@ -33,6 +45,34 @@ Les données partagées sont essentiellement les données des voisins :
 load, to_send et debt.
 
 ========================================================================
 load, to_send et debt.
 
 ========================================================================

+-- Tue, Apr 19 17:48:39 2011 +0200
+
+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
+
+========================================================================
+-- Wed, Mar 9 08:24:40 2011 +0100
+

 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


@@ -59,9 +99,13 @@ $ ./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
 

+-- Thu, Mar 24 16:03:24 2011 +0100
+

 Probablement par un bug dans SG 3.5.
 
 ========================================================================
 Probablement par un bug dans SG 3.5.
 
 ========================================================================

+-- Thu, Jan 27 17:15:02 2011 +0100
+

 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.
 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.


@@ -70,6 +114,8 @@ Le problème devrait être contourné correctement depuis le commit
 cd6b253 Use MSG_comm_waitall for communicator::flush(true).
 
 ========================================================================
 cd6b253 Use MSG_comm_waitall for communicator::flush(true).
 
 ========================================================================

+-- Thu, Jan 27 17:15:02 2011 +0100
+

 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.
 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.


@@ -78,27 +124,3 @@ 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
-
-========================================================================