X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/loba.git/blobdiff_plain/24d1e52d7fe26616e3bee87041acffe889aa4adc..17403ee1430d47714018c5aa0cd159e543a8b401:/BUGS?ds=sidebyside diff --git a/BUGS b/BUGS index 464e620..1f5ee7e 100644 --- a/BUGS +++ b/BUGS @@ -1,25 +1,37 @@ ======================================================================== +-- Wed, Feb 29 16:31:56 2012 +0100 + Les fonctions MSG_get_host{number,table} n'existent plus dans les dernières versions de SimGrid. Utiliser MSG_hosts_as_dynar à la place. ======================================================================== +-- Wed, Feb 29 16:16:45 2012 +0100 + Les exécutions parallèles donnent des résultats différents. Pourquoi ? ======================================================================== +##### MOSTLY RESOLVED BUGS COME AFTER THIS ############################# +======================================================================== +-- 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). ======================================================================== -##### RESOLVED BUGS COME AFTER THIS #################################### -======================================================================== +-- 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. @@ -33,6 +45,34 @@ 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 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 + +======================================================================== +-- Wed, Mar 9 08:24:40 2011 +0100 + Comment expliquer ces différences entre SG 3.5 et SG svn ? $ ./loba platform.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD @@ -59,9 +99,13 @@ $ ./loba-dev platform_dev.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>& [Ginette 1932.076243] [comm/DEBUG] received LOAD: 282.074 from Fafard [Ginette 1940.343540] [comm/DEBUG] received LOAD: 6.19507 from Fafard +-- Thu, Mar 24 16:03:24 2011 +0100 + Probablement par un bug dans SG 3.5. ======================================================================== +-- Thu, Jan 27 17:15:02 2011 +0100 + 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. @@ -70,6 +114,8 @@ Le problème devrait être contourné correctement depuis le commit cd6b253 Use MSG_comm_waitall for communicator::flush(true). ======================================================================== +-- Thu, Jan 27 17:15:02 2011 +0100 + 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. @@ -78,27 +124,3 @@ Le problème devrait être contourné correctement depuis le commit 404a8d5 Do not call flush automatically in communcator::send... ======================================================================== -Valgrind détecte une fuite de mémoire liée à un appel à backtrace. - -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 - -========================================================================