Problem running with the input files generated with 8 and 9 "residuos"

[GoogleCodeExporter]

PROBLEMA:

Estamos realizando diversas pruebas sobre parallel-clusterer, donde pasamos 
archivos comprimidos generados con difernetes residuos. 

Particularmente, corriendolo con archivos generados con 8 y 9 residuos 
respectivamente ( están adjuntos ), se encontraron problemas, tanto con asio 
como con BOINC ( las pruebas por comodidad por ahora las realizamos con asio ).

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

DETALLES DEL PROBLEMA AL EJECUTAR CON ARCHIVO DE 8 RESIDUOS: 

El servidor no termina de procesar todos los resultados enviados por el 
cliente. El handle results de "representatives_job.cpp"
 ( http://code.google.com/p/parallel-clusterer/source/browse/branches/biopp/server/jobs/representatives_job.cpp#34 ) no termina al intentar manejar los resultados de la cuarta job_unit ( Son 5 en total ).

Se estuvo depurando con gdb:

Se colocó breakpoint en la linea:
http://code.google.com/p/parallel-clusterer/source/browse/branches/biopp/server/
jobs/representatives_job.cpp#40 

Pero llega un punto donde a simple vista pareciera no avanzar más o tildarse.

Este problema no ocurria con la version de prot-filer de la revision 59
(http://code.google.com/p/prot-filer/source/detail?r=59)

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

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

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

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

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

DETALLES DEL PROBLEMA AL EJECUTAR CON ARCHIVO DE 9 RESIDUOS: 

El servidor arroja el siguiete mensaje al intentar manejar los resultados de la 
computación del cliente:
"Read error: Read ended without reaching end of structure"

Aqui, el gdb backtrace del thread donde se llama al handle_results:
http://pastebin.com/38Z9ftGy

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

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

OTROS CASOS DE PRUEBA:

Se ejecutó con archivos de 5,6 y 7 residuos sin problemas

Con archivo de 10 residuos no se finalizó la ejecución por el costo de tiempo 
que requería, pero se puede descartar el problema que ocurrió con 9 residuos 
ya que proceso resultados del cliente sin problema.

VERSIONES UTILIZADAS:

Parallel-clusterer ( branche biopp ): revision 152 
(http://code.google.com/p/parallel-clusterer/source/checkout)
prot-filer: revision 65 (http://code.google.com/p/prot-filer/source/browse/)
fud ( asio ): version trunk 
(http://code.google.com/p/parallel-clusterer/source/browse/#svn%2Ftrunk)
backbones_generator: revision 192 
(http://code.google.com/p/backbones-generator/source/browse/)

ACLARACIÓN EXTRA:
Consideramos colocar ambos problemas ( si bien se comportan de manera distinta 
) en un mismo issue porque puede que provengan desde el mismo error.

Original issue reported on code.google.com by rulito...@gmail.com on 9 Aug 2011 at 9:31

Attachments:

• traj8.xz
• traj9.xz

[GoogleCodeExporter]

Comentarios que pueden servir:

Ejecuté el clusterer sobre FuD/BOINC en mi pc con archivos de 5,6,7 y 8 
residuos y me funciona correctamente. Adjunto el resultado obtenido con 8 
residuos: "stats-BOINC_8_resiudos".

Con el archivo de 9 residuos me sucede lo mismo que se detalla en esta issue. 
Actualmente estoy corriendo el clusterer sobre FuD/BOINC con un archivo de 10 
residuos y ,si bien aún no terminó, todo parece funcionar normalmente.

¿Es correcto que con un archivo de 9 residuos se genere ese mensaje de error?

Original comment by lbe...@gmail.com on 15 Aug 2011 at 2:27

Attachments:

• stats-BOINC_8_resiudos

[GoogleCodeExporter]

Dos pruebas que se pueden hacer:

1) leer el archivo con la herramienta de prot-filer (read_compressed)
2) correr el clusterer con full cache (opcion -a creo)

Original comment by hugo.arregui on 15 Aug 2011 at 2:31

[GoogleCodeExporter]

Resultados de las pruebas sobre archivo de 9 residuos:

1) La lectura fue correcta. Ver adjunto "output_read_compressed_r9.txt"

2) Al ejecutar el clusterer con la opción "-a full_cache" el error "Read 
error: Read ended without reaching end of structure" no se produce pero se 
genera un segmentation fault cuando se intenta leer un resultado enviado por el 
cliente. Esto ocurre tanto con FuD/ASIO como con FuD/BOINC.
El error se produce en el mismo lugar pero con job_units diferentes de manera 
aleatoria:
 - con BOINC, el error se produjo al procesar la job_unit con id=19
 - con ASIO en la primer ejecucion, se produjo al procesar la job_unit con id=18
 - con ASIO en la segunda ejecucion, se produjo al procesar la job_unit con id=20
 - con ASIO en la tercer ejecucion, se produjo al procesar la job_unit con id=18
Con esto, descarto que el error sea problema de L1 y probablemente tampoco sea 
problema de L2. 
Ver archivos adjuntos con el backtrace de los errores obtenidos: 
"clusterer_output-r9-full_cache(BOINC)" y "clusterer_output-r9-full_cache(ASIO)"

Original comment by lbe...@gmail.com on 15 Aug 2011 at 3:40

Attachments:

• output_read_compressed_r9.txt
• clusterer_output-r9-full_cache(ASIO)
• clusterer_output-r9-full_cache(BOINC)

[GoogleCodeExporter]

Me parece que el problema es clusterer, acabo de leer el mismo archivo 
utilizando el mismo seteo de SlidingWindowCache que utiliza clusterer y 
funciona perfectamente.

Original comment by hugo.arregui on 15 Aug 2011 at 8:28

[GoogleCodeExporter]

Estoy un poco confundido con estos issues, que es lo que funciona con una 
version vieja de prot-filer? ademas, el reporte original habla de 8 y 9 
residuos, y mas tarde solamente 9. Sugiero que esto se divida en dos issues con 
toda la data actualizada.

(Primero que nada: si hay algo q funciona con la rev X de prot-filer y no con 
la ultima, todavia no lo carguen como issue, mandenme un mail privado y veo si 
puedo resolverlo rapidamente, sino lo cargamos)

Original comment by hugo.arregui on 15 Aug 2011 at 8:45

[GoogleCodeExporter]

Hola Hugo, gracias por el aporte. 

La cuestión es así:
En mi maquina estuve haciendo diversas pruebas del parallel-clusterer. Entre 
ellas, probé con un archivo de 8 residuos el cuál se explica en primer lugar 
del issue. Con ese archivo, el parallel-clusterer "rev152 branche biopp" + 
"prot-filer rev65" no me termina de computar los resultados de la 4ta job_unit 
( pareciera "colgarse" por decirlo de alguna manera ), mientras que con 
"prot-filer rev59" termina todo bien. En ambos casos probé tanto para asio 
como para BOINC. La cuestión está que Lucas no tiene ese problema con el 
archivo de 8 res. por lo que se focalizo en el problema con 9 residuos ( el 
cuál ambos lo tenemos ).

De ultima, finalizo esta issue, cargamos una nueva con el problema que es comun 
para Lucas y para mi ( el problema con archivo de 9 residuos )....y trato de 
ver porque ami no me funciona con archivo de 8 res. y a Lucas si. ( capaz que 
te moleste por mail )

Original comment by rulito...@gmail.com on 16 Aug 2011 at 3:12

[GoogleCodeExporter]

Efectivamente cometi un error en la revision posterior a la que mencionas, asi 
que puede que sea eso, ya esta arreglado, asi que podes probar nuevamente.

De cualquier manera, si, me gustaria marcar este issue como duplicado (o lo que 
sea pertinente), y crear uno o dos issues que con toda la informacion que 
tenemos hasta ahora.

Original comment by hugo.arregui on 16 Aug 2011 at 10:14

[GoogleCodeExporter]

Gracias Hugo

Con la nueva versión de prot-filer no tengo más problemas al correr con un 
archivo de 8 residuos. Sigue tirando el error con el archivo de 9 residuos, 
así que voy a dar por cerrada esta issue y vamos a crear una nueva tratando de 
poner mas detalles sobre el problema.

Original comment by rulito...@gmail.com on 16 Aug 2011 at 1:03

[GoogleCodeExporter]

Raúl, los cambios de Hugo lo q hacen es eliminar memory leaks, me gustaría 
mucho si pudieras confirmar que los bugs eran porque tu máquina se quedaba sin 
memoria,
podrías usar la versión anterior y correr todo mirando top en otra consola? 
(para ver si se queda sin memoria, efectivamente). Esto si no es mucho kilombo, 
sino no importa.
De todas formas, deberían correr todo con Valgrind al menos una vez, alguna 
vez lo hicieron ya?

Original comment by danielgutson@gmail.com on 16 Aug 2011 at 1:14

[GoogleCodeExporter]

Que quilombo.

Sugiero lo siguiente, issue nuevo, un UNICO caso que deberia andar pero se 
rompe.

Determinar si hay lock o crash, son mutuamente excluyentes y no se aceptan 
explicaciones del estilo de "parece que"... se traba o crashea, si no conocen 
la diferencia, preguntan. Si no saben como diferenciar uno del otro, pregunten.

Por lo que ponen acá, parece un crash mientras se trata de leer una 
estructura, un lock mientras se trata de leer una estructura o simplemente la 
función esa tarda muy mucho y ustedes piensan que se trabó.

El handle_results ese es O(n^2), por favor diganmé los tamaños de los dos 
contenedores que recorre para tener una idea del tiempo de cómputo.

Es crucial ahora encontrar el componente que falla. Hasta donde yo veo el 
clusterer tiene un algoritmo O(n^2) que si bien es lento, deberia asegurar 
terminación. Esto me lleva a pensar que hay un problema de manejo de memoria 
en prot-filer, pero no lo puedo asegurar.

Así que por favor, issue nuevo que corresponda a un único problema que falla, 
toda la info ahí. Traten de que sea duplicable el error y determinen en que 
compus falla y en cuales no, me interesa que pasa con la ultima version de 
todo, y como ponen aca, si conocen una version donde todo anda, tambien dejen 
anotado eso.

Si es un crash muestren los valores de las variables en el frame responsable. 
Si es un lock, traten de loggear a partir de que momento se bloquea.

Original comment by billybiset on 16 Aug 2011 at 1:27

[GoogleCodeExporter]

Consideremos tambien armar una sesion de debugging donde uds. nos habilitan una 
consola desde donde podamos hacer ssh y correr un gdb nosotros (Daniel, Hugo y 
yo)

Original comment by billybiset on 16 Aug 2011 at 1:28

[GoogleCodeExporter]

Hola gente.

Daniel, efectivamente se queda sin memoria. Antes de bajar la nueva versión de 
prot-filer estuve probando con BOINC ( antes lo hice con asio ), y este es el 
error que tira:

"Out of memory (Needed 8164 bytes)
Database error: MySQL client ran out of memory"

Valgrind no lo hemos usado todavía, ya estaremos también con eso.

Billy,  gracias por la data, como dije antes, este issue se elimina y vamos a 
crear uno nueva presentando el problema que tenemos con el archivo de 9 
residuos tratando de poner la mayor cantidad de detalles posibles.

Si no hay nada más para agregar, elimino esta issue, y cuando obtengamos más 
detalles del problema que persiste, estaremos creando la nueva.

Original comment by rulito...@gmail.com on 16 Aug 2011 at 1:55

[GoogleCodeExporter]

Original comment by rulito...@gmail.com on 16 Aug 2011 at 4:36

• Changed state: WontFix