BUGS

   1 ========================================================================
   2 -- Wed, Feb 29 16:31:56 2012 +0100
   3
   4 Les fonctions MSG_get_host{number,table} n'existent plus dans les
   5 dernières versions de SimGrid.  Utiliser MSG_hosts_as_dynar à la place.
   6
   7 ========================================================================
   8 -- Wed, Feb 29 16:16:45 2012 +0100
   9
  10 Les exécutions parallèles donnent des résultats différents.
  11 Pourquoi ?
  12
  13 ========================================================================
  14 ##### MOSTLY RESOLVED BUGS COME AFTER THIS #############################
  15 ========================================================================
  16 -- Mon, Feb 27 13:26:08 2012 +0100
  17
  18 Les variables globales process::total_load_* ne sont pas protégées
  19 contre les accès concurrents.  Il n'est donc pas possible actuellement
  20 d'exécuter les simulations en parallèle (--cfg=contexts/nthreads).
  21
  22 -- Wed, Feb 29 15:54:31 2012 +0100
  23
  24 Corrigé en partie.  Il reste quelques "fixme: get locked?" à régler
  25 (ou pas).
  26
  27 ========================================================================
  28 -- Fri, May 20 17:01:33 2011 +0200
  29
  30 Il faut réviser l'utilisation du mutex entre le thread d'équilibrage
  31 et le thread de calcul.  Il semble gardé beaucoup trop longtemps.
  32
  33 -- Tue, May 24 14:55:59 2011 +0200
  34
  35 Bon, une partie du problème est rectifiée par le commit
  36 48de954 Stop locking the mutex on data_receive.
  37
  38 Pour le reste, je pense maintenant que ça ne gêne pas, au moins dans
  39 le simulateur.  Pour faire bien, il faudrait plus séparer les deux
  40 threads d'équilibrage et de calcul, et faire en sorte que chacun garde
  41 un cache des données globales partagées.  Il suffirait alors de
  42 synchroniser ces caches à chaque itération.
  43
  44 Les données partagées sont essentiellement les données des voisins :
  45 load, to_send et debt.
  46
  47 ========================================================================
  48 -- Tue, Apr 19 17:48:39 2011 +0200
  49
  50 Valgrind détecte une fuite de mémoire liée à un appel à backtrace.
  51
  52 Le problème semble être indépendant de SimGrid et peut être reproduit
  53 avec le code suivant (NB: l'équivalent, compilé avec gcc ne génère pas
  54 d'erreur).
  55 ,----
  56 | #include <execinfo.h>
  57 | #include <iostream>
  58 | int main()
  59 | {
  60 |     void *buffer[64];
  61 |     int size = -1;
  62 |     size = backtrace(buffer, sizeof buffer / sizeof buffer[0]);
  63 |     std::cerr << "backtrace() returned " << size << "\n";
  64 | }
  65 `----
  66 ==532== HEAP SUMMARY:
  67 ==532==     in use at exit: 56 bytes in 1 blocks
  68 ==532==     ...
  69 ==532== LEAK SUMMARY:
  70 ==532==    ...
  71 ==532==    still reachable: 56 bytes in 1 blocks
  72
  73 ========================================================================
  74 -- Wed, Mar 9 08:24:40 2011 +0100
  75
  76 Comment expliquer ces différences entre SG 3.5 et SG svn ?
  77
  78 $ ./loba platform.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD
  79 [Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data
  80 [Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data
  81 [Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data
  82 [Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data
  83 [Fafard 2579.229566] [comm/DEBUG] received LOAD: 366.211 from Bourassa
  84 [Fafard 2605.989948] [comm/DEBUG] received LOAD: 20.0806 from Bourassa
  85 [Fafard 2612.318155] [comm/DEBUG] received LOAD: 4.74548 from Bourassa
  86 [Fafard 2616.450666] [comm/DEBUG] received LOAD: 3.09753 from Bourassa
  87
  88 $ ./loba-dev platform_dev.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD
  89 [Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data
  90 [Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data
  91 [Fafard 1519.035900] [comm/DEBUG] received LOAD: 366.211 from Bourassa
  92 [Fafard 1519.035900] [comm/DEBUG] send LOAD: 282.074 to Ginette_data
  93 [Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data
  94 [Fafard 1629.312931] [comm/DEBUG] received LOAD: 20.0806 from Bourassa
  95 [Fafard 1629.312931] [comm/DEBUG] received LOAD: 4.74548 from Bourassa
  96 [Fafard 1629.312931] [comm/DEBUG] send LOAD: 6.19507 to Ginette_data
  97 [Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data
  98 [Fafard 1898.705676] [comm/DEBUG] received LOAD: 3.09753 from Bourassa
  99 [Ginette 1932.076243] [comm/DEBUG] received LOAD: 282.074 from Fafard
 100 [Ginette 1940.343540] [comm/DEBUG] received LOAD: 6.19507 from Fafard
 101
 102 -- Thu, Mar 24 16:03:24 2011 +0100
 103
 104 Probablement par un bug dans SG 3.5.
 105
 106 ========================================================================
 107 -- Thu, Jan 27 17:15:02 2011 +0100
 108
 109 Il semblerait qu'il y ait un bug dans SG 3.5, et qu'on ne puisse pas
 110 utiliser MSG_comm_waitany() pour l'émetteur *et* le récepteur sans
 111 risquer d'interblocage.
 112
 113 Le problème devrait être contourné correctement depuis le commit
 114 cd6b253 Use MSG_comm_waitall for communicator::flush(true).
 115
 116 ========================================================================
 117 -- Thu, Jan 27 17:15:02 2011 +0100
 118
 119 Avec SG 3.5, les communications doivent être détruites dès que
 120 possible avec MSG_comm_destroy().  Si ce n'est pas fait, la simulation
 121 peut être extrêmement ralentie.
 122
 123 Le problème devrait être contourné correctement depuis le commit
 124 404a8d5 Do not call flush automatically in communcator::send...
 125
 126 ========================================================================