2011-06-28 1 views
3

mémoire dlopen/dlsym/dlclose (dlfcn.h) Lorsque vous utilisez la famille dlfcn comme ceci:provoque une fuite

#include <stdio.h> 
#include <dlfcn.h> 

typedef int(*timefunc_t)(void*); 

int main() 
{ 
    timefunc_t fun; 
    void* handle; 
    handle = dlopen("libc.so.6", RTLD_LAZY); 
    fun = (timefunc_t)dlsym(handle, "time"); 
    printf("time=%d\n", fun(NULL)); 
    dlclose(handle); 
    return 0; 
} 

Il provoque une fuite de mémoire:

==28803== Memcheck, a memory error detector 
==28803== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. 
==28803== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info 
==28803== Command: ./dl 
==28803== 
time=1309249569 
==28803== 
==28803== HEAP SUMMARY: 
==28803==  in use at exit: 20 bytes in 1 blocks 
==28803== total heap usage: 1 allocs, 0 frees, 20 bytes allocated 
==28803== 
==28803== LEAK SUMMARY: 
==28803== definitely lost: 0 bytes in 0 blocks 
==28803== indirectly lost: 0 bytes in 0 blocks 
==28803==  possibly lost: 0 bytes in 0 blocks 
==28803== still reachable: 20 bytes in 1 blocks 
==28803==   suppressed: 0 bytes in 0 blocks 
==28803== Rerun with --leak-check=full to see details of leaked memory 
==28803== 
==28803== For counts of detected and suppressed errors, rerun with: -v 
==28803== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 6) 

Ma question est, est-ce une erreur de programmation, ou plutôt un bug dans dlfcn/libdl.so?

+0

@jmbr: Vous devriez publier cela comme réponse, donc je peux l'accepter :-) – hiobs

+0

Est-ce que valgrind n'est pas déjà livré avec des tonnes de règles de suppression qui concernent le chargement de type dl? Exécutez-le à nouveau avec '-v' pour voir s'il n'y a plus ... –

+0

Fait, je vais supprimer le commentaire ici pour éviter la redondance. – jmbr

Répondre

3

On dirait que ce dernier. Cependant cela ne semble pas être un gros problème car si vous répétez le dlopen/dlsym/dlclose appelant une autre routine, vous verrez que la fuite de mémoire est de la même taille, elle ne croît pas avec le nombre d'appels dlopen/dlclose.

+4

Une autre façon de dire ceci est qu'une fuite de mémoire "O (1)" n'est pas une fuite mais une seule goutte. :-) –

+0

Hahah, j'aime ça. – jmbr

Questions connexes