0

グローバル ファイル記述子で fclose を呼び出すと、プログラムがハングします。

クローンによって作成されたいくつかのスレッドが終了した後に発生しました。

以下はシーケンスです。

FILE * fid = fopen("filename", "w");
...
for(int i=0; i<4; i++){
clone((int (*)(void*))do_work, stack[i], CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|SIGCHLD|CLONE_CHILD_CLEARTID|CLONE_PARENT_SETTID|CLONE_IO, NULL, &(ctid[i]), NULL, &(ctid[i]) );
}
...
fclose(fid);

非スレッドは fid を扱います。

strace から、プログラムは "main_arena" を待っている futex でハングします。これはglibc内のミューテックスであるべきだと思います。

バックトレース:

#0  0x0000003f09edf9ee in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x0000003f09e76d31 in _L_lock_5478 () from /lib64/libc.so.6
#2  0x0000003f09e71c8d in _int_free () from /lib64/libc.so.6
#3  0x0000003f09e7273b in free () from /lib64/libc.so.6
#4  0x0000003f09e60d5b in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6

これは、glibc 2.5 を使用する Linux では発生しますが、glibc 2.12 を使用する Linux では発生しません。

このような clone() を使用してスレッドを作成できないためかどうか疑問に思っています。NPTL では、set_robust_futex() やスレッド ローカル ストレージの設定など、さらに多くのことが行われます。

ありがとう！

4

2 に答える 2

0

これがどのように機能するか想像できません。stdioライブラリは内部でロックを使用します。ロックは、使用されているスレッドモデルに固有です。独自のスレッドモデルを使用していますが、stdioライブラリのロックが魔法のように機能することを期待しています。それは明らかに合理的な期待ではありません。

于 2012-02-09T22:17:28.507 に答える
0

カーネルのバージョンは？

カーネルのバグのようです。

詳細については、 futex_wait バグとカーネル パッチを参照してください。

于 2015-12-30T08:40:04.063 に答える