Утечка памяти, о которой сообщил valgrind в dlopen? - PullRequest
13 голосов
/ 09 октября 2009

В последнее время я отлаживал некоторые приложения с помощью valgrind и получаю очень странные отчеты от 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: dlopen@@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: dlopen@@GLIBC_2.2.5 (dlopen.c:88)
        <my call to dlopen>

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

Ответы [ 3 ]

10 голосов
/ 09 декабря 2009

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

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

РЕДАКТИРОВАТЬ (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

2 голосов
/ 06 сентября 2010

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

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

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

1 голос
/ 17 октября 2009

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

...