BUGS

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