X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/loba.git/blobdiff_plain/9a61d03554f90cad51c1e367f20cbf64f90bd75a..2955afe732becd712d718abaf6806aef3c0998a6:/BUGS?ds=inline diff --git a/BUGS b/BUGS index 5cc1040..5fd633b 100644 --- a/BUGS +++ b/BUGS @@ -1,17 +1,99 @@ ======================================================================== -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. +-- Wed, Feb 29 16:16:45 2012 +0100 -Le problème devrait être contourné correctement depuis le commit -cd6b253 Use MSG_comm_waitall for communicator::flush(true). +Les exécutions parallèles donnent des résultats différents. +Pourquoi ? ======================================================================== -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. +##### 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))). + +======================================================================== +-- 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. + +-- 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. + +Pour le reste, je pense maintenant que ça ne gêne pas, au moins dans +le simulateur. Pour faire bien, il faudrait plus séparer les deux +threads d'équilibrage et de calcul, et faire en sorte que chacun garde +un cache des données globales partagées. Il suffirait alors de +synchroniser ces caches à chaque itération. + +Les données partagées sont essentiellement les données des voisins : +load, to_send et debt. + +======================================================================== +-- Tue, Apr 19 17:48:39 2011 +0200 + +Valgrind détecte une fuite de mémoire liée à un appel à backtrace. -Le problème devrait être contourné correctement depuis le commit -404a8d5 Do not call flush automatically in communcator::send... +Le problème semble être indépendant de SimGrid et peut être reproduit +avec le code suivant (NB: l'équivalent, compilé avec gcc ne génère pas +d'erreur). +,---- +| #include +| #include +| int main() +| { +| void *buffer[64]; +| int size = -1; +| size = backtrace(buffer, sizeof buffer / sizeof buffer[0]); +| std::cerr << "backtrace() returned " << size << "\n"; +| } +`---- +==532== HEAP SUMMARY: +==532== in use at exit: 56 bytes in 1 blocks +==532== ... +==532== LEAK SUMMARY: +==532== ... +==532== still reachable: 56 bytes in 1 blocks ========================================================================