Linux上でクローンされたスレッドの後でfcloseがハングする

Question

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

これは、クローンによって作成された複数のスレッドの終了後に発生しました。以下は

配列であるFIDと

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); 

非スレッドを扱っています。

straceから、プログラムは "main_arena"を待つfutexでハングします。私はこれがglibcの中にいくつかのmutexであるべきだと思う。

バックトレース：

#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.12とLinux上のglibc 2.5、ではなくて、Linux上で起こります。

このようにclone（）を使ってスレッドを作成することができないのかどうかは疑問です。 NPTLでは、set_robust_futex（）やスレッドローカルストレージの設定など、もっと多くのことが行われます。

ありがとうございます！

Answer 1

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

Answer 2

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

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

futex_wait bugおよびkernel patchを参照してください。