Pruebas con Valgrind y uso de SWAP en paginación

[jcastagno99]

Buenas! tengo 2 consultas puntuales y que nada tienen que ver entre sí.

1) Hay algo muy raro en querer hacer la prueba de estabilidad con paginación corriendo el modulo de mi-ram-hq con valgrind, el flujo se queda trabado, el mapa hace cosas raras y la ejecución no termina, no se si tiene que ver con algo de que estoy al borde de la memoria, pero solo me pasa con valgrind y en la prueba de estabilidad (solo con esta combinación), no hay semaforos sin liberar ni nada, corro la misma prueba con la misma configuración (que es la misma que se dice en el documento de pruebas pero con el ciclo de CPU en 0.1 y RAM con paginación) pasa perfecto. Alguna idea del porque? deberia pasar? tengo entendido que no se pide evaluar con valgrind Dejo una foto de lo que hace el mapa (no se si suma pero la dejo) :

La consola queda como bloqueada y no tira ningun error (ninguno de los 3 modulos)

2) Me gustaría saber si esta bien como estoy tratando el Swap : Yo voy cargando procesos en memoria principal y cuando no hay lugar empiezo a Swapear, les asigno a cada página un "inicio en swap" y cuando hay que traer dicha pagina a memoria, copio desde swap a un frame, pero como que siempre una vez guardada en swap queda residualmente una "copia", lo que se me ocurre de ultima es cuando me la traigo, copiarle basura por encima, pero me parece innecesario, estaria bien dejarlo asi? no es que hago un duplicado de entrada, cuando necesito swapear una pagina por primera vez, la mando a swap, y cuando la quiero traer, leo esa posicion N bytes del tamaño de las paginas y la copio a un frame que apunta a la memoria principal, es correcto?

[iago64]

Buenas! ¿Cómo va?

1.- No es que no se pida, directamente esta prohibido levantar los procesos con valgrind en la entrega final. Igual sería bueno saber que output tira valgrind como para ver si efectivamente no es que te esta pasando que tenes algún manejo medio raro de la memoria.

2.- La pagina tiene que estar en memoria principal o en swap, no puede estar en ambos lados al mismo tiempo, por mas que sea una versión desactualizada.

Saludos.-

[jcastagno99]

Buenas, creo que la respuesta 2 me dejo mal parado, voy a detallar un poco mejor como vengo haciendo el tema de swap (que creo que ahí esta el problema)

2) Yo hasta ahora al inicio del modulo hago MMAP para levantar el area de swap, cuando me van llegando paginas para guardarlas en swap voy asignandoles un lugar en el mismo: hago un memcpy a inicio_swap + offset_swap de N bytes y corro el puntero de offset_swap para no pisar otra pagina y le asigno ese lugar con un puntero, para luego si ya tenia un lugar en swap no volver a cargar la pagina en otro, yo no estoy manejando estructuras que me digan que lugar de swap esta libre o no, simplemente voy escribiendo con un offset, entiendo entonces que deberia hacer un analogo a los frames de memoria para administrar lugares libres / ocupados en swap? Así cuando me traigo algo de swap a memoria, lo copio de un "frame_swap" a un "frame_posta" y marco el de swap como libre para que alguien lo pise de ser necesario, asi no tengo "duplicados" , bueno tendria el duplicado hasta que alguien pise el dato pero en esencia no estaria duplicado. Este es el enfoque correcto? con esto cumplo lo de no duplicados? De otra forma no se me ocurre como poder manejar lugares libres/ocupados con mi implementacion actual.

Si ese enfoque estaba bien, hay algun criterio para elegir un "frame_swap" libre? o es el primero que encuentro?

1) Me olvide de agregarlo antes, perdon deja este mensaje cuando corto el modulo (porque se queda bloqueado) y apreto cualquier tecla en la consola de Mi-Ram-HQ

[dteplitz]

Aca dejo el .log que genera el valgrind cuando tira este error.

Me llama mucho la atencion porque en el mapa se mueven letras afuera del cuadrado pintado y hasta repite algunos caracteres cosa que entiendo no deberia poder pasar. Y encima sin valgrind esta funcionando correctamente. valgrind.log

Tambien me llama la atencion que con paginacion rompe, pero con segmentacion no...

[iago64]

Buenas, cómo va?

Al parecer el problema lo tenes en tu función buscar_patota_con_tid_paginacion (mi-ram-hq-lib.c:798), estas buscando algo que no esta reservado o que le hiciste free() previamente. Por eso con segmentación te anda y con paginación no.

Saludos.-

[jcastagno99]

Si creo que estaba mal sincronizado esa funcion con la de expulsar tripulante, me llegaban cosas concurrentes y buscaba iterando listas que no existian, ya agregué unos semaforos y a veces funciona perfecto (llego a una función de cierre que me libera todo) pero otras veces no entiendo que pasa con algo de pthread exit, pero esto de los hilos está igual para segmentación y ahí no pasa nada (dejo el valgrind de cuando pasa eso) [Este valgrind es de la prueba de paginación con el ciclo de CPU a 0] valgrind-log.txt.txt

tambien agrego como dato (que no se si sirve pero me parece muy raro) cuando suele rompe el numero de socket (que nosotros lo logueamos para controlar) se eleva mucho, en este caso creo que llega a 31 (estoy haciendo el test de paginacion) pero en el test de estabilidad, me paso que llego a 350 + y despues se colgó

Sobre el tema del swap, estaría bien lo que digo arriba?

[iago64]

Buenas! ¿Cómo va?

Mientras otro proceso pueda ocupar ese "frame" de swap esta bien :)

Saludos.-

[jcastagno99]

Perfecto, cierro eso de swap.

Ahora el tema este de valgrind... no puedo ubicar cual es el problema, corrí la prueba de estabilidad con paginación SIN VALGRIND y lo mire con htop (las corrí desde mi vm local) para ver si estaba teniendo un leak o algo

Así arranca cuando inicio los 3 modulos

Así queda cuando le cargo todas las patotas, inicio planificación y espero a que termine

Y así es cuando termina y cierro los 3 modulos, cuando cierro esos modulos libero todo lo que me reserve, creo que no hay un leak como tal, el inicio y el final es aproximado porque la VM hace cosas en el medio y a veces suma o resta cosas.

Ahora, cuando levanto Mi-Ram-HQ con valgrind cambia.

Así arranca

Llega un punto en el que los modulos se congelan, Ram solo queda logeando, discordiador se traba y el flujo no termina, cuando llega a este punto corto los modulos y me tira un Seg Fault en una función de cierre (que libera listas globales y eso que la llamo con el SIG INT) pero es que en sí el modulo se traba antes de tirarle el Ctrl + C y no puedo saber porque.

Dejo el log de valgrind (que dice lo que menciono arriba de la función de cierre) y el log del modulo

valgrind-log.txt

mi-ram-log.txt

Es medio dificil de verlo así capaz por el labo lo pueda replicar mejor

[RaniAgus]

¡Buenas! Antes que nada, quisiera hacer el mismo comentario que acá: https://github.com/sisoputnfrba/foro/issues/2221#issuecomment-881960522 . Es por esto que no existe ningún motivo para handlear SIGINT.

De hecho, esto altera las estadísticas que tira Valgrind, ya que quizás en ese handler estén liberando alguna estructura administrativa que no estén usando y deban haberla liberado en ejecución. Quizás sea la razón por la cual, por más que Valgrind les tire que solo tienen 8 bytes en "definitely lost", a hora de probar el módulo sin Valgrind éste crezca 21 MB (lo cual es un montonazo).

EDIT: (me olvidé de lo más importante lol) Estaría bueno que quiten ese handler para que sepamos cuál es el output de Valgrind solamente en ejecución.

Saludos

[jcastagno99]

Buenas! ahí estuve haciendo eso que me dijiste, simplemente saque el handler y no libero ninguna estructura administrativa, el log de valgrind no me dice mucho a mi pero paso todos los datos nuevos:

Estado cuando solamente abri htop :

Estado cuando levanto los 3 modulos, levantar RAM con valgrind me ocupo algo de 130 M (no se como funcióna internamente valgrind y si esto es normal)

Estado cuando inicio todas las patotas (todavía no planifico nada) :

En un punto los 3 modulos se traban, ninguno explota ni tira seg fault, parecieria "un semaforo sin liberar" pero cuando la corro sin valgrind (misma configuración y todo) termina sin problemas por eso no me cierra... Estado cuando se traba todo antes de que lo cierre:

El log de valgrind : Valgrind-log.txt (perdón no se si les gusta que les pase el log en txt o preferirían que lo copie directamente aca no se que les es mas comodo)

Todos los still reachables son los que yo antes liberaba con la función de cierre y los definitely lost siguen siendo 8 bytes =/

//-------------------- Para corroborar corro la misma prueba pero sin valgrind -----------

Recuerdo es la prueba de estabilidad del documento de pruebas finales pero con paginación y con ciclo de CPU 0, el resto sigue siendo la misma configuración

Así arranca:

Cuando levante los 3 modulos: (quedo igual)

Cuando cargue todas las patotas con iniciar patota:

Y cuando finalizo la planificación (si que crecio alrededor de 20M)

Puede ser un leak entonces? no estaría pudiendo ubicarlo

Edit: Agrego las funciones que menciona valgrind :

void *esperar_conexion(int puerto)
{
    int socket_escucha = iniciar_servidor_mi_ram_hq(puerto);
    int socket_mi_ram_hq;
    log_info(logger_ram_hq, "SERVIDOR LEVANTADO! ESCUCHANDO EN %i", puerto);
    struct sockaddr cliente;
    socklen_t len = sizeof(cliente);
    do
    {
        socket_mi_ram_hq = accept(socket_escucha, &cliente, &len);
        if (socket_mi_ram_hq > 0)
        {
            log_info(logger_ram_hq, "NUEVA CONEXIÓN! Socket id: %i",socket_mi_ram_hq);
            crear_hilo_para_manejar_suscripciones(socket_mi_ram_hq);
        }
        else
        {
            log_error(logger_ram_hq, "ERROR ACEPTANDO CONEXIONES: %s", strerror(errno));
        }
    } while (1);
}

void crear_hilo_para_manejar_suscripciones(int socket)
{
    int *socket_hilo = malloc(sizeof(int));
    *socket_hilo = socket;
    pthread_t hilo_conectado;
    pthread_attr_t atributo_hilo;
    pthread_attr_init(&atributo_hilo);
    pthread_attr_setdetachstate(&atributo_hilo, PTHREAD_CREATE_DETACHED);
    pthread_create(&hilo_conectado, &atributo_hilo, (void *)manejar_suscripciones_mi_ram_hq, socket_hilo);
    return;
}

Update: Sigo buscando donde esta el problema, hasta ahora lo unico que pude lograr es achicar el "área de busqueda", no es un tema de mi VM y es un tema específico de paginación, por lo que esas funciones de arriba (que son generales para los 2 esquemas) no son el problema, segmentación funciona con y sin valgrind y no hace crecer el modulo mas de 3M aproximadamente, ahora, valgrind no me dice nada sobre ningun leak en paginación. En general uso muchas mas estructuras administrativas en paginación (bastantes mas, las cuales manejo con t_list, según valgrind 52498 bytes quedaron malloqueados, que tampoco me cierra la cuenta de todas formas y no explica porque no funciona con valgrind el modulo)

Update2: No encontre ningun problema, revise todos los mutex y todos los mallocs ya por ultimo corrí la prueba de paginación del documento de pruebas, pasa con o sin valgrind, el log de valgrind directamente no me marca ningun byte definitivamente perdido o indirectamente perdido, solo los still reachable

(Modulos levantados)

(cuando finaliza la planificación)

Log de valgrind:

Valgrin-prueba-paginacion.txt

Y ya como remate, corrí la prueba que dije antes (la de paginación) sin valgrind y desde que lo levanto, le cargo patotas, lo corro y todo la memoria se mantiene igual (y termina todo sin problemas)

[iago64]

Buenas! Cómo va?

OJO porque still reachable, lo que significa es que todavía lo podías recuperar, simplemente que como lo funaste con Ctrl + C quedo ahí en el limbo. De valgrind lo que SI es leak son: definitely lost y indirectly lost

Respecto al problema de lo que te queda bloqueado, probaste con helgrind a ver si te detecta algún deadlock?

Saludos.-

[jcastagno99]

Buenas, intente usar helgrind con la prueba de estabilidad y me comio toda la memoria y el swap, la VM se colgó y tuve que cerrar todo, el log tiraba muchisimas cosas, corrí la prueba de paginación (que no explota) y fui arreglando de a poco, me quedó uno que no entiendo el porque (y que se repite bastante), es sobre el orden de como se toman unos semaforos y todas las funciones tienen problema con lo mismo, no entiendo mucho de como leer helgrind igual parece que me dice que no se puede tomar un semaforo antes que otro, pero se toma y se libera en el momento, dejo el Log y uno de los conflictos (son de todas las funciones con una en especifico practicamente)

Helgrind-log.txt

El conflicto lo tiene por ejemplo el primer mutex dentro del while (el auxiliar_pagina->mutex_pagina)

    tarea_ram* tarea_contador;
    tarea_ram* tarea_especifica = list_get(patota->tareas,indice_proxima_tarea);
    proxima_tarea = malloc(tarea_especifica->tamanio);
    t_pagina* auxiliar_pagina;
    double tamanio_hasta_tarea = 2*(sizeof(uint32_t));
    for(int i=0; i<indice_proxima_tarea; i++){
        tarea_contador = list_get(patota->tareas,i);
        tamanio_hasta_tarea += tarea_contador->tamanio;
    }

    double indice_de_tarea = tamanio_hasta_tarea / mi_ram_hq_configuracion->TAMANIO_PAGINA;
    double offset_hasta_tarea = modf(indice_de_tarea,&indice_de_tarea);
    int offset_hasta_tarea_entero = offset_hasta_tarea * mi_ram_hq_configuracion->TAMANIO_PAGINA;

    int bytes_de_tarea = tarea_especifica->tamanio;
    int bytes_leidos_tarea = 0;
    int indice_auxiliar_tarea = indice_de_tarea;
    int espacio_disponible_en_pagina = mi_ram_hq_configuracion->TAMANIO_PAGINA - offset_hasta_tarea_entero;
    int offset_pagina_entero = offset_hasta_tarea_entero;

    while(bytes_leidos_tarea < bytes_de_tarea){
        auxiliar_pagina = list_get(patota->paginas,indice_auxiliar_tarea);
        pthread_mutex_lock(auxiliar_pagina->mutex_pagina);
        if(!auxiliar_pagina->presente){
            frame = buscar_frame_libre();
            if(!frame){
                if(!strcmp(mi_ram_hq_configuracion->ALGORITMO_REEMPLAZO,"LRU")){
                    frame = sustituir_LRU();
                }
                if(!strcmp(mi_ram_hq_configuracion->ALGORITMO_REEMPLAZO,"CLOCK")){
                    frame = sustituir_CLOCK();
                }
            }
            pthread_mutex_lock(frame->mutex);
            auxiliar_pagina->presente = 1;
            auxiliar_pagina->inicio_memoria = frame->inicio;
            auxiliar_pagina->uso = 1;
            frame->pagina_a_la_que_pertenece = auxiliar_pagina;
            frame->indice_pagina = auxiliar_pagina->id_pagina;
            frame->pid_duenio = patota->id_patota;
            frame->libre = 0;
            pthread_mutex_lock(auxiliar_pagina->frame_swap->mutex);
            memcpy(frame->inicio,auxiliar_pagina->frame_swap->inicio,mi_ram_hq_configuracion->TAMANIO_PAGINA);
            auxiliar_pagina->frame_swap->libre = 1;
            pthread_mutex_unlock(auxiliar_pagina->frame_swap->mutex);
            t_pagina_y_frame* frame_y_pagina = malloc(sizeof(t_pagina_y_frame));
            frame_y_pagina->frame = frame;
            frame_y_pagina->pagina = auxiliar_pagina;

            pthread_mutex_lock(&mutex_lru);
            list_add(historial_uso_paginas,frame_y_pagina);
            pthread_mutex_unlock(&mutex_lru);
        }
        else if(auxiliar_pagina->presente){
            int indice = buscar_frame_y_pagina_con_tid_pid(auxiliar_pagina->id_pagina,patota->id_patota);

            pthread_mutex_lock(&mutex_lru);
            t_pagina_y_frame* frame_y_pagina = list_remove(historial_uso_paginas,indice);
            pthread_mutex_unlock(&mutex_lru);

            frame = frame_y_pagina->frame;
            pthread_mutex_lock(frame->mutex);

            pthread_mutex_lock(&mutex_lru);
            list_add(historial_uso_paginas,frame_y_pagina);
            pthread_mutex_unlock(&mutex_lru);
        }
        if((bytes_de_tarea - bytes_leidos_tarea) > espacio_disponible_en_pagina){
            memcpy(proxima_tarea + bytes_leidos_tarea,auxiliar_pagina->inicio_memoria + offset_pagina_entero,espacio_disponible_en_pagina);
            bytes_leidos_tarea += espacio_disponible_en_pagina;
            espacio_disponible_en_pagina =  mi_ram_hq_configuracion->TAMANIO_PAGINA;
            offset_pagina_entero = 0;
            auxiliar_pagina->uso = 1;
            pthread_mutex_unlock(auxiliar_pagina->mutex_pagina);
            indice_auxiliar_tarea++;
        }
        else{
        memcpy(proxima_tarea + bytes_leidos_tarea,auxiliar_pagina->inicio_memoria + offset_pagina_entero,bytes_de_tarea - bytes_leidos_tarea);
        bytes_leidos_tarea = bytes_de_tarea;
        auxiliar_pagina->uso = 1;
        pthread_mutex_unlock(auxiliar_pagina->mutex_pagina);
        }
     pthread_mutex_unlock(frame->mutex);
    } 

con esta función que es la que se repite en todos los conflictos del log:

En actualizar pagina es el mutex de pagina->mutex_pagina;

 t_frame_en_memoria* sustituir_LRU(){
    log_info(logger_ram_hq,"inicio algoritmo de sustitucion LRU");
    pthread_mutex_lock(&mutex_lru);
    t_pagina_y_frame* pagina_a_quitar_con_su_frame = list_remove(historial_uso_paginas,0);
    pthread_mutex_unlock(&mutex_lru);
    actualizar_pagina(pagina_a_quitar_con_su_frame->pagina);
    //pagina_a_quitar_con_su_frame->pagina->presente = 0;
    log_info(logger_ram_hq, "se ha elegido como victima a la pagina %i del proceso %i", pagina_a_quitar_con_su_frame->pagina->id_pagina,pagina_a_quitar_con_su_frame->frame->pid_duenio);
    t_frame_en_memoria* a_retornar;
    a_retornar = pagina_a_quitar_con_su_frame->frame;
    free(pagina_a_quitar_con_su_frame);
    return a_retornar;
}

void actualizar_pagina(t_pagina* pagina){

    //pthread_mutex_lock(&mutex_swap);
    pthread_mutex_lock(pagina->mutex_pagina);
    t_frame_en_swap* auxiliar = buscar_frame_swap_libre();
    if(!auxiliar){
        log_error(logger_ram_hq,"Se pidio buscar un frame en swap pero no habia ninguno disponible");
        pthread_mutex_unlock(pagina->mutex_pagina);
        //pthread_mutex_unlock(&mutex_swap);
        exit -1;
    }
    pthread_mutex_lock(auxiliar->mutex);
    pagina->frame_swap = auxiliar;
    memcpy(pagina->frame_swap->inicio,pagina->inicio_memoria,mi_ram_hq_configuracion->TAMANIO_PAGINA);
    pagina->frame_swap->libre = 0;
    pagina->presente = 0;
    pagina->inicio_memoria = NULL;
    pthread_mutex_unlock(auxiliar->mutex);
    pthread_mutex_unlock(pagina->mutex_pagina);
    //pthread_mutex_unlock(&mutex_swap);

}

Pareciera que se lockea una pagina y luego se la vuelve a lockear, pero no es ese el tema, la primer función es parte de obtener tarea, toma una pagina y la blockea, pregunta si esta en memoria o no y de no estarlo llama al algortimo de sustitucion (en este caso el LRU que llama al actualizar pagina) pero la pagina que se actualiza en actualizar_pagina es una pagina que estaba presente en memoria, es decir, que ocupaba un frame, por lo que nunca van a ser la misma pagina`

Update: Aun con eso que menciono arriba pendiente, la prueba de estabilidad sin valgrind a veces pasa a veces crashea y con valgrind sigue igual, llega hasta un punto y se traba y no me dice nada (helgrind en la de estabilidad directamente me crashea la vm)

[iago64]

Buenas!

Ojo, el "problema" que tenes ahi es que helgrind asume que vos estas tomando mal los semáforos, pero no puede asegurarlo, lo importante es que no te esta detectando deadlocks, lo que si estaría bueno es ver si con estos cambios que hiciste gracias a helgrind, que esta devolviendo valgrind, porque capaz tengas algo de memoria que se esta sobrescribiendo y por eso se le tranca el paty a tu proceso.

Saludos.-

[jcastagno99]

Buenas! no lo mencione en ese momento porque me habia roto todo y estuve todo el día tratando de hacer que ande, logre hacer que funcione la prueba de estabilidad pero sin valgrind, ya con las correcciones de helgrind hechas (menos esas de ahí arriba) valgrind sigue rompiendo, se traba en algun punto y ningun modulo avanza (igual que antes), lo termino con un control + c y el log es el mismo, todos bytes still reachable y 8 definitely lost que son del hilo que yo mato con el control + c, de todas formas hoy probe tambien esta prueba en las VM de la nube (creo que se les dice asi) SIN VALGRIND y la memoria no aumenta mas de 1M (tengo estructuras que no libero porque saque la funcion de cierre, creo que eso influye un poco en ese crecimiento), creo que para lo que se pide en las pruebas esta bien, pero sigue siendo raro que valgrind no me lo corra.

Habia pensado en un punto que podia ser porque me capea la memoria de la VM, siempre que se traba llega a 881 aprox y ahi cuelga todo, nunca se el log completo porque lo tengo que cerrar a mano, pero es una teoría nada mas, perdón por el choclo de texto, dejo el log de valgrind con los cambios de helgrind ya hechos :

Nuevo valgrind log.txt

Ya como dato, helgrind en la misma prueba me capea la memoria, el swap y la cpu vuela al 100% y ahí mueren gatitos

Ah, tambien logramos solucionar que se salian las letras del mapa cuando lo ejecutamos con valgrind, era agregar unos mutex a las funciones de dibujado, pero eso no hace que funcione con valgrind, solo que el mapa no haga cosas raras.

[iago64]

Buenas! Una consulta, como estan ejecutando valgrind? que parametros le estan pasando? porque de todo el bruto choclo que tienen solo importa 1 cosa:

==28507== Thread 53:
==28507== Conditional jump or move depends on uninitialised value(s)
==28507==    at 0x8051EED: obtener_direccion_movimiento_mapa (mi-ram-hq-lib.c:2953)
==28507==    by 0x804B7DA: actualizar_ubicacion_paginacion (mi-ram-hq-lib.c:732)
==28507==    by 0x804A32D: manejar_suscripciones_mi_ram_hq (mi-ram-hq-lib.c:298)
==28507==    by 0x4062294: start_thread (pthread_create.c:333)
==28507==    by 0x41E10AD: clone (clone.S:114)
==28507==  Uninitialised value was created by a stack allocation
==28507==    at 0x804B82C: leer_un_uint32_a_partir_de_indice (mi-ram-hq-lib.c:739)

Pero despues de eso, no dice nada de memoria pisada ni de conflictos de memoria, con lo cual no habría mayores inconvenientes. Por otro lado, el LEAK SUMMARY, esta perfecto, despues de toda la ejecución perdieron 8 bytes nomas:

==28507== LEAK SUMMARY:
==28507==    definitely lost: 8 bytes in 2 blocks
==28507==    indirectly lost: 0 bytes in 0 blocks
==28507==      possibly lost: 0 bytes in 0 blocks
==28507==    still reachable: 176,646 bytes in 2,342 blocks
==28507==         suppressed: 0 bytes in 0 blocks

Saludos.-

[jcastagno99]

Buenas, valgrind lo ejecutamos con un comando que se llama "vexec" (hicimos el tp en visual) el comando esta configurado así :

#!/bin/bash
FILE=mi-ram-hq
make $FILE
if test -f "./$FILE"; then
    valgrind --tool=memcheck --track-origins=yes --leak-check=full --show-leak-kinds=all --show-possibly-lost=no --show-reachable=yes --num-callers=20 --log-file="cfg/valgrind.log" ./$FILE cfg/mi-ram-hq.config cfg/mi-ram-hq.log
fi

Hay varios flags para valgrind, el --log-file es el path donde guardamos el log de valgrind a parte y despues los parametros del $FILE (que seria el ejecutable del modulo) el primero es el path al archivo de configuracion y el segundo es el path a donde queremos guardar el log general del modulo

Show possibly-lost=no, tengo entendido que no te muestra el tracking pero en el leak summary aparecen si o si (que aca marca 0)

Sobre de que no hay leaks, nunca pude terminar toda la ejecución con valgrind siempre se traba y lo tengo que terminar yo, por lo que no se al 100% si no hay algo raro mas adelante desde que se traba (aunque lo lógico seria que lo que hace que se traba este antes de que se trabe) pero por las dudas corrimos simulaciones con htop y no vimos un crecimiento excesivo como antes así que la verdad que nose porque lo hace.

Y sobre el salto condicional, lo voy a revisar ahora y updateo pero no me cierra que sin valgrind funcione todo y con valgrind se cuelguen los modulos de la nada, o por lo menos no lo entiendo.

[iago64]

Buenas!

Definitivamente siento que el haber dejado ese issue pineado que explica como usar VSCode hizo mas daño de lo que ayudo. Paso a comentarte que esta de mas y/o podrían sacarlo

--tool=memcheck  # Te dice basicamente que uses valgrind, solo tiene sentido si usas helgrind
--track-origins=yes # Esta bien, podes dejarlo-
--leak-check=full # Justamente esto te sirve, queres todos los leaks
--show-leak-kinds=all # Tambien dejalo, te dice todos los tipos de leaks.
--show-possibly-lost=no # Bien que este en "no", ya que no te interesa lo posiblemente perdido, te lo sumariza abajo.
--show-reachable=yes # Podes sacarlo, no te interesa saber que memoria podes recuerar todavia
--num-callers=20 # Podes sacarlo, no te interesa decirle a valgrind hasta cuantas lineas del stack queres leer, por defecto te trae casi siempre todo lo que necesitas

De todas formas, teniendo en cuenta que no tenes grandes leaks segun lo que se ve en el último log, no me preocuparía mucho mas por valgrind.

Saludos-

[jcastagno99]

Perfecto, si por las dudas corrimos varias veces con HTOP y no vimos nada raro, pero bueno corroborar no venia mal. Cierro issue entonces, gracias!