fclose在Linux上的克隆線程後掛起

Question

在全局文件描述符上調用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，程序掛在futex等待「main_arena」。我認爲這應該是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 

這發生在Linux上用glibc 2.5，但不能在Linux上用glibc 2.12。

我在想，是不是因爲我們不能用這樣的clone（）創建線程。在NPTL中，完成了更多的事情，比如set_robust_futex（）和seting線程本地存儲。

謝謝！

Answer 1

我無法想象你會如何期待這個工作。 stdio庫在內部使用鎖。鎖是特定於正在使用的線程模型的。您正在使用自己的線程模型，但期望stdio庫的鎖定可以神奇地使用它。這顯然不是一個合理的期望。

Answer 2

你的內核版本是什麼？

這似乎是一個內核錯誤。

請參閱futex_wait bug和kernel patch瞭解更多信息。