5

しばしばデッドロックする単体テストがいくつかあります。GDB を詳しく調べると、次のことがわかります。

スレッド 1:

(gdb) ところで
#0 0x00110424 in __kernel_vsyscall ()
#1 /lib/libc.so.6 からの __lll_lock_wait_private () 内の 0x00c681a3
#2 /lib/libc.so.6 の _L_lock_515 () 内の 0x00bf09fb
#3 /lib/libc.so.6 の tr_mallochook() で 0x00bf068c
#4 /lib/libc.so.6 からの calloc() で 0x00bece22
#5 /lib/ld-linux.so.2 の _dl_new_object () 内の 0x00b5ed93
#6 /lib/ld-linux.so.2 からの _dl_map_object_from_fd () 内の 0x00b5b287
#7 /lib/ld-linux.so.2 の _dl_map_object () 内の 0x00b5c521
#8 /lib/ld-linux.so.2 からの dl_open_worker () の 0x00b66f43
#9 /lib/ld-linux.so.2 からの _dl_catch_error () の 0x00b629a6
#10 /lib/ld-linux.so.2 からの _dl_open() 内の 0x00b66a06
#11 /lib/libdl.so.2 からの dlopen_doit() で 0x00d38c3b
#12 /lib/ld-linux.so.2 の _dl_catch_error () で 0x00b629a6
#13 /lib/libdl.so.2 の _dlerror_run() で 0x00d3903c
#14 0x00d38b71 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2
...

スレッド 2:

#0 0x00110424 in __kernel_vsyscall ()
#1 /lib/libpthread.so.0 からの __lll_lock_wait() 内の 0x00d4c059
#2 /lib/libpthread.so.0 からの _L_lock_752 () 内の 0x00d4740e
#3 /lib/libpthread.so.0 からの pthread_mutex_lock () の 0x00d4731a
#4 /lib/libc.so.6 からの _dl_addr() 内の 0x00c95dd2
#5 /lib/libc.so.6 の tr_where() で 0x00bf0425
#6 /lib/libc.so.6 からの tr_mallochook() 内の 0x00bf06bd
#7 /lib/libc.so.6 からの malloc() の 0x00bed01b
....

私はインターネットで多くの検索を行いましたが、私が何か間違ったことをしているのか、それともライブラリにバグを見つけたのか、本当にわかりません。

4

1 に答える 1

5

glibc のdlopen()コードはスレッドセーフではないようです。

コードが2 つのスレッドから同時に呼び出しmalloc()ているように見えます。また、呼び出しが未解決の動的シンボルにヒットし、 を使用して解決しようとしているdlopen()ようにも見えます。これは、実行しているバイナリが遅延バインディング (デフォルトの動作) でリンクされていたことを意味します。これが、ランタイム リンカーが最初の呼び出しで要求に応じてシンボルを解決する理由です。アプリケーションを開始する前に、実行時リンカーがすべてのシンボルを解決するようにするには、リンカー オプションを使用してリンクしてみてください。malloc()_dl_addr()ld-Wl,-z,now gcc

このバグは、私がバグ レポートを提出したバグと似ています。

于 2012-08-14T14:53:06.430 に答える