Muy a menudo escribo pruebas en mis programas para asegurarme de que funcionen el 100% del tiempo bajo cualquier circunstancia (para que luego no tenga que pasar horas depurándolos).
Sin embargo, todas mis pruebas hasta ahora solo estaban probando las líneas de código que puedo alcanzar en circunstancias normales, por lo que, por ejemplo, no probé qué sucedería si fallara malloc() . Sin embargo, también quiero hacer eso, así que recientemente comencé a experimentar y buscar respuestas sobre cómo anular cualquier función para que devuelva cualquier valor predefinido y posiblemente establezca errno en algún valor.
Aprendí sobre dlsym, LD_PRELOAD y --wrap para el enlazador. Hasta ahora, he tenido muchos éxitos con dlsym, incluso anulando malloc() y no caería en un bucle infinito, sin embargo, Valgrind que estoy usando para encontrar fugas de memoria parece ignorar felizmente cualquier función que envuelvo con dlsym y entonces, por ejemplo, malloc() comienza a actuar normalmente cuando no quiero que lo haga bajo Valgrind (y por lo tanto devolver NULL artificialmente no funciona).
LD_PRELOAD se usa bastante junto con dlsym, en realidad no hace nada por sí solo.
--wrap es bueno y todo, pero su defecto es que necesita saber las funciones que desea anular para cada archivo. Eso es aburrido: con dlsym puedo elegir las funciones en mi código y eso es todo, pero --wrap hará que mi Makefile sea significativamente más complicado.
También intenté usar las definiciones ocultas de libc ( __libc_malloc() , __libc_function_name() en general) para anular los símbolos débiles de malloc() , strxxx() y otras funciones que a Valgrind le gusta anular y luego usar dlsym para todo lo demás, tipo de así:
void* __libc_malloc(size_t); void* malloc(size_t size) { if(malloc_fail) { errno = ENOMEM; return NULL; } return __libc_malloc(size); }Pero, de nuevo, Valgrind también anularía felizmente esta implementación de malloc y me dejaría sin ninguna opción.
También intenté cambiar mi detector de fugas de memoria a algo como libasan ( gcc -fsanitize=address ), pero desafortunadamente tengo una experiencia muy terrible con los desinfectantes que vienen con gcc, debido a su implementación defectuosa que, por ejemplo, falla al usar pthread_cancel() ( como aquí ), y resulta que mi código necesita probar también algunas funciones pthread, porque las estoy envolviendo en mis propias funciones y estructuras y esas cosas.
¿Hay alguna otra forma de activar rutas de código erróneas? ¿Estoy haciendo algo mal?
Valgrind proporciona sus propios envoltorios para malloc , calloc y free , y esto es esencial para su funcionamiento. No me sorprende en absoluto que estos desplacen cualquier envoltorio que intente especificar para esas funciones. La principal alternativa sería la inversa: sus envoltorios desplazando a los de valgrind.
Sugiero simplemente segregar sus pruebas en aquellas que dependen de que usted inyecte sus envoltorios y aquellas que no. Use Valgrind solo con pruebas del último grupo.
La forma de hacer esto sería llamar a sus funciones de otra manera que no sea malloc , etc. (como my_malloc ).
Y si hace eso y aún desea que Valgrind analice la memoria devuelta por my_malloc , deberá usar el mecanismo de cliente de Valgrind para informarle a Valgrind sobre su grupo de memoria, asignaciones, etc.
Echa un vistazo a este artículo para ver un ejemplo.