BUGS

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