X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/loba.git/blobdiff_plain/652e6a2a0580b932a3a1fd14c0c64db41454c22e..8185d5cdd5d8fd1b4c78888a6add91b93f0cfcc0:/BUGS?ds=sidebyside diff --git a/BUGS b/BUGS index 040cfc3..de42340 100644 --- a/BUGS +++ b/BUGS @@ -1,10 +1,55 @@ ======================================================================== +-- 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. + +-- Tue, 06 Mar 2012 17:02:02 +0100 + +Le patch suivant corrige le problème : +--- a/hostdata.cpp ++++ b/hostdata.cpp +@@ -19,8 +19,9 @@ void hostdata::create() + using std::placeholders::_1; + using std::placeholders::_2; + +- int nhosts = MSG_get_host_number(); +- m_host_t* host_list = MSG_get_host_table(); ++ xbt_dynar_t host_dynar = MSG_hosts_as_dynar(); ++ int nhosts = xbt_dynar_length(host_dynar); ++ m_host_t* host_list = static_cast(xbt_dynar_to_array(host_dynar)); + // only sort hosts for automatically created deployment + if (opt::auto_depl::enabled) + std::sort(host_list, host_list + nhosts, + ======================================================================== -##### RESOLVED BUGS COME AFTER THIS #################################### +-- 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). + +======================================================================== +-- 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. @@ -18,51 +63,8 @@ Les données partagées sont essentiellement les données des voisins : load, to_send et debt. ======================================================================== -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 -[Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data -[Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data -[Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data -[Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data -[Fafard 2579.229566] [comm/DEBUG] received LOAD: 366.211 from Bourassa -[Fafard 2605.989948] [comm/DEBUG] received LOAD: 20.0806 from Bourassa -[Fafard 2612.318155] [comm/DEBUG] received LOAD: 4.74548 from Bourassa -[Fafard 2616.450666] [comm/DEBUG] received LOAD: 3.09753 from Bourassa - -$ ./loba-dev platform_dev.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD -[Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data -[Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data -[Fafard 1519.035900] [comm/DEBUG] received LOAD: 366.211 from Bourassa -[Fafard 1519.035900] [comm/DEBUG] send LOAD: 282.074 to Ginette_data -[Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data -[Fafard 1629.312931] [comm/DEBUG] received LOAD: 20.0806 from Bourassa -[Fafard 1629.312931] [comm/DEBUG] received LOAD: 4.74548 from Bourassa -[Fafard 1629.312931] [comm/DEBUG] send LOAD: 6.19507 to Ginette_data -[Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data -[Fafard 1898.705676] [comm/DEBUG] received LOAD: 3.09753 from Bourassa -[Ginette 1932.076243] [comm/DEBUG] received LOAD: 282.074 from Fafard -[Ginette 1940.343540] [comm/DEBUG] received LOAD: 6.19507 from Fafard - -Probablement par un bug dans SG 3.5. - -======================================================================== -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. +-- Tue, Apr 19 17:48:39 2011 +0200 -Le problème devrait être contourné correctement depuis le commit -cd6b253 Use MSG_comm_waitall for communicator::flush(true). - -======================================================================== -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. - -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