From: Arnaud Giersch <arnaud.giersch@iut-bm.univ-fcomte.fr>
Date: Thu, 1 Mar 2012 15:05:27 +0000 (+0100)
Subject: BUGS: add missing dates.
X-Git-Tag: exp_20120308~15
X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/loba.git/commitdiff_plain/17403ee1430d47714018c5aa0cd159e543a8b401?ds=inline

BUGS: add missing dates.
---

diff --git a/BUGS b/BUGS
index 464e620..1f5ee7e 100644
--- 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.
 
 ========================================================================
+-- Wed, Feb 29 16:16:45 2012 +0100
+
 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).
 
+-- Wed, Feb 29 15:54:31 2012 +0100
+
 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.
 
+-- 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.
 
@@ -33,6 +45,34 @@ Les données partagées sont essentiellement les données des voisins :
 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
@@ -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
 
+-- Thu, Mar 24 16:03:24 2011 +0100
+
 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.
@@ -70,6 +114,8 @@ Le problème devrait être contourné correctement depuis le commit
 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.
@@ -78,27 +124,3 @@ 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
-
-========================================================================