Version 0.4.

[loba.git] / BUGS

diff --git a/BUGS b/BUGS
index 040cfc39fd3af4fcb16a7aa4aacf161a2315ec69..5fd633b52cc6cb8d24fc4d8443e4c5fb49eb0720 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1,10 +1,63 @@
 ========================================================================
 ========================================================================

+-- 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 #############################
+========================================================================
+-- Wed, 02 May 2018 10:48:05 +0200
+
+Fort ralentissement d'un facteur 2, voire plus, avec les versions récentes de
+SimGrid (3.18, 3.19.1).  Il semblerait que l'utilisation d'exceptions en cas de
+timeout dans les simcalls soit coûteuse. À vérifier.
+
+-- Mon, 07 May 2018 16:05:49 +0200
+
+Les exceptions ne sont plus utilisées depuis le commit
+8efeb3a6aa2c201800a3ba19416ea9728af3bff6 (Stop using costly exceptions on
+timeout for simix synchros).
+
+Le ralentissement restant dans lmm_solve() semble venir essentiellement du
+commit f3677661714bf6122d678071c0bd44141417be14 (Fix bug #17132 (surf.c:366: The
+Impossible Did Happen (yet again))).
+

 ========================================================================
 ========================================================================

-##### RESOLVED BUGS COME AFTER THIS ####################################
+-- Wed, 02 May 2018 10:44:41 +0200
+
+Ne fonctionne pas avec les versions de SimGrid de 3.8 à 3.12 inclus : la
+simulation ne démarre pas (le thread "compute" déployé automatiquement n'est pas
+exécuté).
+
+Le problème est introduit par le commit e6d1ca27d8852f9922141ea15eae6b339c2d2bc7
+(Completely remove surfxml_callback. Clean the way to create arg for the
+process.), puis corrigé par le commit bb66fe3993929c5d1b25e4982502869d725cefd7
+([platf] Kill sg_process_cb).
+
+Avec des versions plus récentes, plante après la fin de la simulation (SIGSEGV)
+pour les versions de SimGrid de 3.13 à 3.17 inclus.
+

 ========================================================================
 ========================================================================

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


@@ -18,51 +71,8 @@ Les données partagées sont essentiellement les données des voisins :
 load, to_send et debt.
 
 ========================================================================
 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.
+-- Tue, Apr 19 17:48:39 2011 +0200

 
 

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