Утечка памяти, сообщенная valgrind in dlopen?

Я недавно отлаживал какое-то приложение с valgrind, и я получаю очень странные отчеты от dlopen.Утечка памяти, сообщенная valgrind in dlopen?

==1987== 32 bytes in 1 blocks are still reachable in loss record 1 of 2 
==1987== at 0x4C24477: calloc (vg_replace_malloc.c:418) 
==1987== by 0x570F31F: _dlerror_run (dlerror.c:142) 
==1987== by 0x570EEE0: [email protected]@GLIBC_2.2.5 (dlopen.c:88) 
     <my call to dlopen> 
==1987== 
==1987== 264 bytes in 1 blocks are still reachable in loss record 2 of 2 
==1987== at 0x4C25153: malloc (vg_replace_malloc.c:195) 
==1987== by 0x400CD44: _dl_map_object_deps (dl-deps.c:506) 
==1987== by 0x4012DA2: dl_open_worker (dl-open.c:326) 
==1987== by 0x400E385: _dl_catch_error (dl-error.c:178) 
==1987== by 0x40126C6: _dl_open (dl-open.c:615) 
==1987== by 0x570EF65: dlopen_doit (dlopen.c:67) 
==1987== by 0x400E385: _dl_catch_error (dl-error.c:178) 
==1987== by 0x570F2AB: _dlerror_run (dlerror.c:164) 
==1987== by 0x570EEE0: [email protected]@GLIBC_2.2.5 (dlopen.c:88) 
     <my call to dlopen>

Это выглядит как сообщение об ошибке, которое инициализируется для dlerror, но, глядя на странице человека, он ничего не знает о том, как это должно быть очищено не сказать. Любая идея, как правильно избавиться от этого?

источник

2009-10-09 Anteru

вы используете 'dlclose()'? – LiraNuna

Да, конечно, я дважды проверял, что dlclose правильно вызван, но только если dlopen что-то возвращает! = NULL, и я подозреваю, что это из случаев, когда dlopen _does_ return 0 – Anteru

Был в состоянии воспроизвести эту проблему с кодом «hello world», который даже не вызывает никаких символов в загруженном объекте. http://pastebin.com/d690bea57

Я предполагаю, что это ошибка в libc или valgrind. Воспроизводимые по Ubuntu 9.04 и Scientific Linux 5.3 (соответственно 20 и 32 байта).

EDIT (по Calmarius):

Этот тривиальный код воспроизводит проблему:

#include <dlfcn.h> 

int main() 
{ 
    void* handle = 0; 

    handle = dlopen("libm.so", RTLD_NOW); 
    dlclose(handle);  

    return 0; 
}

Когда скомпилированные с помощью этой команды:

gcc -Wl,--no-as-needed -g -o stuff main.c -ldl -lpthread

Даже последняя VALGRIND 3,11 может воспроизвести это на Ubuntu 14.04

Сообщается об ошибке: https://bugs.kde.org/show_bug.cgi?id=358980

источник

2009-12-09 14:37:49

Друг указал, что это ошибка в Valgrind. https://issues.asterisk.org/view.php?id=16007 См. Прилагаемый файл подавления valgrind. –

Я узнал, что valgrind не сообщит об этой утечке, если вы закончите свой код с помощью pthread_exit (NULL), даже если вы вообще не используете pthreads. Может быть, это может помочь кому-то. Это может быть менее громоздко, чем писать файл подавления valgrind. –

Я предполагаю, что вызов pthread_exit очищает локальное хранилище потоков, которое используется для хранения текста ошибки (чтобы он был многопоточным, вам просто нужно связать нить между вызовами dlopen и dlerror). – KayEss

Я видел это сам во всех видах libs, используя dlopen или нет. Я просто предположил, что это была какая-то волшебная реализация внутри libs, которая обманула valgrind - или - у этих libs действительно есть утечки памяти, и в этом случае я ничего не могу сделать в моем приложении.

источник

2009-10-16 22:35:11

Это подавление лучше:

{ 
    Ignore dlopen bug. 
    Memcheck:Leak 
    ... 
    fun:_dl_open 
    ... 
}

(. Обратите внимание, что "..." является частью подавления и должны быть введены в буквальном смысле)

источник

2010-09-06 07:56:11 StellarVortex

Утечка памяти, сообщенная valgrind in dlopen?

ответ

Смежные вопросы