死锁 (fork + malloc) libc (glibc-2.17, glibc-2.23)

Question

我运行遇到了一个非常烦人的问题：我有一个在开始时创建一个线程的程序，该线程将在其执行期间启动其他内容（fork() 紧接着 execve()）。

这是我的程序达到（我认为）死锁点时两个线程的 bt：

线程 2（LWP 8839）：

#0 0x00007ffff6cdf736 在 __libc_fork () at ../sysdeps/nptl/fork.c:125

#1 _IO_new_proc_open 中的 0x00007ffff6c8f8c0 (fp=fp@entry=0x7ffff00031d0, command=command@entry=0x7ffff6c26e20 "ps -u brejon | grep \"cvc\"

#2 _IO_new_popen 中的 0x00007ffff6c8fbcc（命令=0x7ffff6c26e20 "ps -u user | grep \"cvc\" | wc -l"，模式=0x42c7fd "r"）在 iopopen.c:296

#3-4 ...

#5 0x00007ffff74d9434 在 start_thread (arg=0x7ffff6c27700) 在 pthread_create.c:333

#6 0x00007ffff6d0fcfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

线程 1（LWP 8835）：

#0 __lll_lock_wait_private () 在 ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95

#1 0x00007ffff6ca0ad9 在 malloc_atfork (sz=140737337120848, caller=) 在 arena.c:179

#2 __GI__IO_file_doallocate 中的 0x00007ffff6c8d875 (fp=0x17a72230) 在 filedoalloc.c:127

#3 0x00007ffff6c9a964 在 __GI__IO_doallocbuf (fp=fp@entry=0x17a72230) 在 genops.c:398

#4 0x00007ffff6c99de8 在 _IO_new_file_overflow (f=0x17a72230, ch=-1) 在 fileops.c:820

#5 0x00007ffff6c98f8a in _IO_new_file_xsputn (f=0x17a72230, data=0x17a16420, n=682) 在 fileops.c:1331

#6 _IO_vfprintf_internal 中的 0x00007ffff6c6fcb2（s=0x17a72230，格式=，ap=ap@entry=0x7fffffffcf18）在 vfprintf.c:1632

#7 0x00007ffff6c76a97 在 __fprintf（流=，格式=）在 fprintf.c:32

#8-11 ...

#12 0x000000000042706e 位于mains/ignore/.c:146

glibc-2.17 和 glibc-2.23 都永远停留在这里

欢迎任何帮助:'D

编辑：

这是一个最小的例子：

  1 #include <stdlib.h>
  2 #include <pthread.h>
  3 #include <unistd.h>
  4 
  5 void * thread_handler(void * args)
  6 {
  7         char * argv[] = { "/usr/bin/ls" };
  8         char * newargv[] = { "/usr/bin/ls", NULL };
  9         char * newenviron[] = { NULL };
 10         while (1) {
 11                 if (vfork() == 0) {
 12                         execve(argv[0], newargv, newenviron);
 13                 }
 14         }
 15 
 16         return 0;
 17 }
 18 
 19 int main(void)
 20 {
 21         pthread_t thread;
 22         pthread_create(&thread, NULL, thread_handler, NULL);
 23 
 24         int * dummy_alloc;
 25 
 26         while (1) {
 27                 dummy_alloc = malloc(sizeof(int));
 28                 free(dummy_alloc);
 29         }
 30 
 31         return 0;
 32 }

环境： user:deadlock$猫/etc/redhat-release

科学 Linux 7.3 版（氮气）

user:deadlock$ ldd --version

ldd（GNU libc）2.17

编辑 2： rpm包版本为：glibc-2.17-196.el7.x86_64

~~我无法使用 rpm 包获取行号。这是使用发行版中给出的 glibc 的 BT：~~ 用 debuginfo 解决。

(gdb) 线程应用所有 bt

线程 2（线程 0x7ffff77fb700 (LWP 59753)）：

#0 vfork () 在../sysdeps/unix/sysv/linux/x86_64/vfork.S:44

#1 0x000000000040074e 在 thread_handler (args=0x0) 在 deadlock.c:11

#2 start_thread 中的 0x00007ffff7bc6e25 (arg=0x7ffff77fb700) 在 pthread_create.c:308

#3 0x00007ffff78f434d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

线程 1（线程 0x7ffff7fba740 (LWP 59746)）：

#0 0x00007ffff7878226 在 _int_free（av=0x7ffff7bb8760，p=0x602240，have_lock=0）在 malloc.c:3927

#1 0x00000000004007aa in main () at deadlock.c:28

Answer 1

这是自定义编译的 glibc。安装可能出了问题。请注意，Red Hat Enterprise Linux 7.4 backports a fix for a deadlock between malloc and fork, and you are missing that because you compiled your own glibc. The fix for the upstream bug 仅进入上游版本 2.24，因此如果您的自定义构建基于该版本，则可能没有此修复。（尽管那个回溯看起来会有所不同。）

我认为我们至少修复了另一个 post-2.17 libio 相关的死锁错误。

EDIT 我处理与 fork 相关的死锁已经太久了。复制器存在多个问题，如 posted:

没有 waitpid 调用 PID。结果，进程 table 将很快充满僵尸。
execve 没有错误检查。如果 /usr/bin/ls 路径名不存在（例如，在未经历 UsrMove 的系统上），execve 将 return，并且循环的下一次迭代将启动另一个vfork电话。

我解决了这两个问题（因为调试接近叉子炸弹的东西一点也不好玩），但我无法重现 glibc-2.17-196.el7 的挂起。x86_64.

死锁 (fork + malloc) libc (glibc-2.17, glibc-2.23)

Deadlock (fork + malloc) libc (glibc-2.17, glibc-2.23)

c

deadlock

libc