c - 死锁(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 ...

pthread_create.c:333 处的 start_thread (arg=0x7ffff6c27700) 中的#5 0x00007ffff74d9434

克隆()中的#6 0x00007ffff6d0fcfd位于../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 in malloc_atfork (sz=140737337120848, caller=) at arena.c:179

#2 0x00007ffff6c8d875 在 __GI__IO_file_doallocate (fp=0x17a72230) 在 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 在 main (argc=3, argv=0x7fffffffd698, envp=0x7fffffffd6b8) 处 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 }

环境:用户: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 () 位于 ../sysdeps/unix/sysv/linux/x86_64/vfork.S:44

deadlock.c:11 处 thread_handler (args=0x0) 中的#1 0x000000000040074e

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

克隆()中的#3 0x00007ffff78f434d位于../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 相关的死锁已经太久了。发布的再现器存在多个问题:

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

我修复了这两个问题(因为调试接近 fork 炸弹的东西一点也不有趣)，但我无法使用 glibc-2.17-196.el7.x86_64 重现挂起。