Muchos pthreads: programa corre sin errores con valgrind, pero no sin

[Sgwa]

En mi programa para la primera funcionalidad, hago un pthread de map por cada linea del archivo, lo que causa que se vayan generando muchos. (y 20 pthreads para los reduces).

Al correrlo con el text.txt de los test que nos entregaron no hay ningun problema y el output lo entrega correctamente al correrlo tanto con valgrind como sin (en valgrind no hay ningun leak ni error de ningun tipo)

Pero al correr el text2.txt (de mas de mil lineas no vacias), valgrind dice que sobrepaso el maximo de threads y que use --max-threads=INT para subir el maximo de threads.

Asi al correr mi programa con valgrind --max-threads=2000 ./mapreduce Tests/text2.txt out.txt threads todo bien sin ningun tipo de error:

Pero al correrlo sin valgrind (./mapreduce Tests/text2.txt out.txt threads) el programa se cae:

Me di cuenta que a veces como en la foto dice:

• *** Error in './mapreduce': double free or corruption (!prev): 0x0000000000dbbbb0 *** y otras:
• *** Error in './mapreduce': realloc(): invalid next size: 0x000000000249b250 ***

Nose si alguien sabria decirme que es lo que esta pasando aqui.

[IchottMano]

Hola!

En el caso de que a cada thread le asignes un thread, no es factible que instancies todos los threads a la vez, intenta esperar que algunos threads terminen antes de instanciar mas, lo cual puede que arregle tu problema de memoria.

Posiblemente tu problema con realloc es que al hacer tantos realloc, no haya suficiente memoria libre para hacer realloc, lo cual implica que el realloc fallará.

Saludos!

[Sgwa]

Quize ir al extremo y puse un sleep de 0.05 segundos, y cada thread map alcanza a terminar antes de que parta el siguiente, pero de igual forma ahora aparece:

• Aborted (core dumped) sin ningun detalle:

Y con valgrind sigue corriendo sin leaks y ningun tipo de error.

[Sgwa]

poniendo el sleep entre la creacion de los threads de reduce lo pude solucionar! Gracias!

[IchottMano]

Hola!

Que bueno que tu problema se haya solucionado, sin embargo intenta usar pthread_join en vez de un sleep para manejar tus threads, ya que puede que estos demoren mas o que el sleep aumente demasiado el tiempo de tu programa.

Saludos!

[Sgwa]

Al final era otro el problema! me faltaba definir otra parte del codigo del reduce como zona critica y ponerle un lock. En esa parte del codigo hace realloc a cierta variable que esta definida fuera en el main().

Con eso no tengo que poner ningun sleep y el programa corre a su maximo de velocidad (casi instantaneo), nose porque este problema no surge cuando se prueba con valgrind, quizas valgrind se asegura que los pedidos de memoria no se cruzen (?)

Igual creo que no lo tengo solucionado del todo, si lo ejecuto seguidas veces aprox 1 de cada 15 termina en segmentation fault (core dumped).