BUGS

   1 ========================================================================
   2 -- Wed, Feb 29 16:16:45 2012 +0100
   3
   4 Les exécutions parallèles donnent des résultats différents.
   5 Pourquoi ?
   6
   7 ========================================================================
   8 ##### MOSTLY RESOLVED BUGS COME AFTER THIS #############################
   9 ========================================================================
  10 -- Wed, 02 May 2018 10:48:05 +0200
  11
  12 Fort ralentissement d'un facteur 2, voire plus, avec les versions récentes de
  13 SimGrid (3.18, 3.19.1).  Il semblerait que l'utilisation d'exceptions en cas de
  14 timeout dans les simcalls soit coûteuse. À vérifier.
  15
  16 -- Mon, 07 May 2018 16:05:49 +0200
  17
  18 Les exceptions ne sont plus utilisées depuis le commit
  19 8efeb3a6aa2c201800a3ba19416ea9728af3bff6 (Stop using costly exceptions on
  20 timeout for simix synchros).
  21
  22 Le ralentissement restant dans lmm_solve() semble venir essentiellement du
  23 commit f3677661714bf6122d678071c0bd44141417be14 (Fix bug #17132 (surf.c:366: The
  24 Impossible Did Happen (yet again))).
  25
  26 ========================================================================
  27 -- Wed, 02 May 2018 10:44:41 +0200
  28
  29 Ne fonctionne pas avec les versions de SimGrid de 3.8 à 3.12 inclus : la
  30 simulation ne démarre pas (le thread "compute" déployé automatiquement n'est pas
  31 exécuté).
  32
  33 Le problème est introduit par le commit e6d1ca27d8852f9922141ea15eae6b339c2d2bc7
  34 (Completely remove surfxml_callback. Clean the way to create arg for the
  35 process.), puis corrigé par le commit bb66fe3993929c5d1b25e4982502869d725cefd7
  36 ([platf] Kill sg_process_cb).
  37
  38 Avec des versions plus récentes, plante après la fin de la simulation (SIGSEGV)
  39 pour les versions de SimGrid de 3.13 à 3.17 inclus.
  40
  41 ========================================================================
  42 -- Mon, Feb 27 13:26:08 2012 +0100
  43
  44 Les variables globales process::total_load_* ne sont pas protégées
  45 contre les accès concurrents.  Il n'est donc pas possible actuellement
  46 d'exécuter les simulations en parallèle (--cfg=contexts/nthreads).
  47
  48 -- Wed, Feb 29 15:54:31 2012 +0100
  49
  50 Corrigé en partie.  Il reste quelques "fixme: get locked?" à régler
  51 (ou pas).
  52
  53 ========================================================================
  54 -- Fri, May 20 17:01:33 2011 +0200
  55
  56 Il faut réviser l'utilisation du mutex entre le thread d'équilibrage
  57 et le thread de calcul.  Il semble gardé beaucoup trop longtemps.
  58
  59 -- Tue, May 24 14:55:59 2011 +0200
  60
  61 Bon, une partie du problème est rectifiée par le commit
  62 48de954 Stop locking the mutex on data_receive.
  63
  64 Pour le reste, je pense maintenant que ça ne gêne pas, au moins dans
  65 le simulateur.  Pour faire bien, il faudrait plus séparer les deux
  66 threads d'équilibrage et de calcul, et faire en sorte que chacun garde
  67 un cache des données globales partagées.  Il suffirait alors de
  68 synchroniser ces caches à chaque itération.
  69
  70 Les données partagées sont essentiellement les données des voisins :
  71 load, to_send et debt.
  72
  73 ========================================================================
  74 -- Tue, Apr 19 17:48:39 2011 +0200
  75
  76 Valgrind détecte une fuite de mémoire liée à un appel à backtrace.
  77
  78 Le problème semble être indépendant de SimGrid et peut être reproduit
  79 avec le code suivant (NB: l'équivalent, compilé avec gcc ne génère pas
  80 d'erreur).
  81 ,----
  82 | #include <execinfo.h>
  83 | #include <iostream>
  84 | int main()
  85 | {
  86 |     void *buffer[64];
  87 |     int size = -1;
  88 |     size = backtrace(buffer, sizeof buffer / sizeof buffer[0]);
  89 |     std::cerr << "backtrace() returned " << size << "\n";
  90 | }
  91 `----
  92 ==532== HEAP SUMMARY:
  93 ==532==     in use at exit: 56 bytes in 1 blocks
  94 ==532==     ...
  95 ==532== LEAK SUMMARY:
  96 ==532==    ...
  97 ==532==    still reachable: 56 bytes in 1 blocks
  98
  99 ========================================================================