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

Question

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

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

线程 2 (LWP 8839)：

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

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

#2 0x00007ffff6c8fbcc in _IO_new_popen (command=0x7ffff6c26e20 "ps -u user | grep \"cvc\" | wc -l", mode=0x42c7fd "r") at iopopen.c:296

#3-4 ...

#5 0x00007ffff74d9434 in start_thread (arg=0x7ffff6c27700) at 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 () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95

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

#2 0x00007ffff6c8d875 in __GI__IO_file_doallocate (fp=0x17a72230) at filedoalloc.c:127

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

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

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

#6 0x00007ffff6c6fcb2 in _IO_vfprintf_internal (s=0x17a72230, format=, ap=ap@entry=0x7fffffffcf18) at vfprintf.c:1632

#7 0x00007ffff6c76a97 in __fprintf (stream=, format=) at fprintf.c:32

#8-11 ...

#12 0x000000000042706e in main (argc=3, argv=0x7fffffffd698, envp=0x7fffffffd6b8) at 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$ cat /etc/redhat-release

Scientific Linux 7.3 版（氮气）

用户：死锁$ 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 () at ../sysdeps/unix/sysv/linux/x86_64/vfork.S:44

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

#2 0x00007ffff7bc6e25 in start_thread (arg=0x7ffff77fb700) at pthread_create.c:308

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

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

#0 0x00007ffff7878226 in _int_free (av=0x7ffff7bb8760 , p=0x602240, have_lock=0) at 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，因为您编译了自己的 glibc，所以您错过了这一点。 fix for the upstream bug 仅适用于上游版本 2.24，因此如果您的自定义构建基于此，您可能没有此修复程序。 （尽管那个回溯看起来会有所不同。）

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

编辑 我处理与 fork 相关的死锁已经太久了。发布的复制器存在多个问题：

• 没有waitpid 调用PID。结果，进程表将很快被僵尸填满。
• execve 没有错误检查。如果/usr/bin/ls 路径名不存在（例如，在没有经历UsrMove 的系统上），execve 将返回，循环的下一次迭代将启动 另一个 @987654328 @调用。

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