search

billybiset / parallel-clusterer

Automatically exported from code.google.com/p/parallel-clusterer
0 stars 0 forks source link

Error processing client results after reading file generated with 9 residuos #12

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
PROBLEMA:

Error en el server del parallel clusterer al ejecutarlo con un archivo de 9 
residuos.
Los errores se generan cuando el server maneja resultados enviados por el 
cliente

DETALLES:

Se realizaron casos de prueba variando la política de cache.

--------------------------------------------------------------------------------
------------------------------

Con la politica "protein_sliding_window", el server arroja el siguiente error:
"Read error: Read ended without reaching end of structure", durante la 
ejecución del "handle_result" de representatives jobs, tras recibir desde el 
cliente los resultados de procesar la primera job_unit.

PARA REPRODUCIR EL PROBLEMA:

El archivo se creó de esta manera:
./petu -i data -r 9 -w compressed

De esta manera se corre el server del clusterer:
./clusterer -i traj9.xz -f compressed -s stats

De esta manera se corre el client del clusterer:
./clusterer-client -a 127.0.0.1 -p 31337

--------------------------------------------------------------------------------
------------------------------

Con la política "full_cache" se procesan todos los resultados de 
"representatives_job", pero el server arroja
"segmentation fault" en el handle_result de "clusters_job". Este error se da al 
intentar procesar diferentes job_units.

PARA REPRODUCIR EL PROBLEMA:

El archivo se creó de esta manera:
./petu -i data -r 9 -w compressed

De esta manera se corre el server del clusterer:
./clusterer -i traj9.xz -f compressed -s stats -a "full_cache"

De esta manera se corre el client del clusterer:
./clusterer-client -a 127.0.0.1 -p 31337

Ver adjunto archivo "clusterer_output-r9-full_cache(ASIO)" donde se plasma el 
backtrace del "segmentation fault"

--------------------------------------------------------------------------------
------------------------------

OTRA PRUEBA:
Se realizó una prueba con la herramienta "read_compressed" de prot-fler, pero 
la salida fue correcta.( ver adjunto "output_read_compressed_r9.txt")

VERSIONES UTILIZADAS:

Parallel-clusterer ( branche biopp ): revision 152
prot-filer: revision 67
fud ( asio ): version trunk (Revisión del último cambio: 366)
backbones_generator: revision 192

Original issue reported on code.google.com by rulito...@gmail.com on 18 Aug 2011 at 2:56

Attachments:

GoogleCodeExporter commented 9 years ago 
Gente, por favor actualicen prot-filer y vuelvan a probar, acabo de arreglar al 
menos uno de los bugs (es raro, todavia ni se como armar el test para esto).

Original comment by hugo.arregui on 20 Aug 2011 at 7:46

GoogleCodeExporter commented 9 years ago 
Hugo, asi medio rapido intente compilar pero me tira error, te adjunto el 
archivo con los errores.

Original comment by rulito...@gmail.com on 21 Aug 2011 at 1:29

Attachments:

GoogleCodeExporter commented 9 years ago 
actualiza mili tambien

Original comment by hugo.arregui on 21 Aug 2011 at 1:32

GoogleCodeExporter commented 9 years ago 
Actualicé a las últimas versiones de prot-filer (revis 73) y mili (revis 238) 
y corri el clusterer con las dos cache policy. En ambos casos obtuve un 
segmentation fault en la misma ubicación. Ver archivos adjuntos con los 
detalles.

Original comment by lbe...@gmail.com on 21 Aug 2011 at 10:53

Attachments:

GoogleCodeExporter commented 9 years ago 
Perfecto, por eso decia que eran dos issues a separar. El primero esta 
solucionado, asi que habria que actualizar esto y dejar solo la info relevante.

Original comment by hugo.arregui on 21 Aug 2011 at 11:08

GoogleCodeExporter commented 9 years ago 
Gente, preguntas: que es lo que pasa en clusterer cuando se cuelga? en que 
estado esta, cuantos jobs se procesaron? que muestra el log?

Original comment by hugo.arregui on 22 Aug 2011 at 11:02

GoogleCodeExporter commented 9 years ago 
Hola Hugo, aca intento dar algunas respeustas:

Cuando el clusterer tira "segmentation fault", lo que está haciendo es 
procesar los resultados de las job_units correspondientes a ClustersJob, luego 
de procesar bien todos los resultados de RepresentativesJob ( 15 jobs ). 
Siempre tira el fault en resultados de distintas job_units, generalmente entre 
la 18 y 22 hasta donde probamos. ( La primer job_unit de ClustersJob es la 16 )

Por el momento es la info que te podemos dar, más los dos archivos que subió 
lucas en el comentario anterior. Vamos a seguir depurando para ver si logramos 
sacar mas detalles!

Si sabes de alguna prueba que podamos hacer o algunas recomendaciones, 
bienvenido sea!

Original comment by rulito...@gmail.com on 23 Aug 2011 at 4:59

GoogleCodeExporter commented 9 years ago 
En el comentario anterior, pase la cantidad de jobunits que se procesaban antes 
de actualizar prot-filer.

Ahora, para RepresentativesJob se procesar de manera correcta 26 job units.
A partir de la job_unit 27, se comienzan a procesar los resultados de los 
trabajos de ClustersJob, donde según las pruebas, siempre me tiro 
"segmentation fault" en la línea 
http://code.google.com/p/parallel-clusterer/source/browse/branches/biopp/server/
jobs/clusters_job.cpp#83 luego de 10 iteraciones del "for".

Original comment by rulito...@gmail.com on 24 Aug 2011 at 3:06

GoogleCodeExporter commented 9 years ago 
Gente, acá les paso la solución del problema reflejado en este issue que 
encontraron Billy y Hugo en la debug session, la cual quedo colgada en un mail 
con asunto "Fix Bug Parallel Cluster - Issue12":

Lo que causaba el segmentation fault era que en la linea 83:
http://code.google.com/p/parallel-clusterer/source/browse/trunk/server/jobs/clus
ters_job.cpp#83
se estaba accediendo a la posición "it->second" la cual era "1042" cuando el 
tamaño del vector clusters (_clusters.size() ) era de 1023.

El problema estaba en la linea 110:
http://code.google.com/p/parallel-clusterer/source/browse/branches/biopp/server/
jobs/clusters_job.cpp#110
cuando el servidor armaba la jobUnit donde se le pasaba la proteína a 
diferencia de la versión del trunk linea 107:
http://code.google.com/p/parallel-clusterer/source/browse/trunk/server/jobs/clus
ters_job.cpp#107
donde se utiliza ProteinRefWithClusterID para pasar el ClusterID como el 
ProteinID.

La solución fue modificar la linea 110:
http://code.google.com/p/parallel-clusterer/source/browse/branches/biopp/server/
jobs/clusters_job.cpp#110

por:
(*res) << ClusterID(i);
(*res) << protein.getItemVector();

Para ello también se tuvo que agregar el metodo getItemVector() en la clase 
Structure:
http://code.google.com/p/biopp/source/browse/biopp/prot_structure/Structure.h
ya que el vector _item_vector no era visible desde clusters_job.cpp. El código 
de este nuevo método es el siguiente:

inline const std::vector<Item>& getItemVector() const
{
    return _item_vector;
}

Quedaron dudas respecto de si era correcto agregar este get() o no.

Original comment by rulito...@gmail.com on 19 Nov 2011 at 6:24