16

最近、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、man ページを見ると、これをクリアする方法については何も書かれていません。これを正しく取り除く方法はありますか？

4

3 に答える 3

11

この問題は、ロードされたオブジェクトでシンボルを呼び出すことさえしない「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

于 2009-12-09T14:37:49.533 に答える
4

この抑制は優れています。

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

(「...」は抑制の一部であり、文字どおりに入力する必要があることに注意してください。)

于 2010-09-06T07:56:11.830 に答える