The execve action allocated the arrays in the forked child process. However, in a multi-threaded program we might have forked while another thread had the malloc lock. In that case, the child would wait forever because it inherited the locked mutex but not the thread that would unlock it. e.g.
#0 futex_wait (private=0, expected=2, futex_word=0xffff9509cb10 <main_arena>) at ../sysdeps/nptl/futex-internal.h:146
#1 __GI___lll_lock_wait_private (futex=futex@entry=0xffff9509cb10 <main_arena>) at ./nptl/lowlevellock.c:34
#2 0x0000ffff94f8e780 in __libc_calloc (n=<optimized out>, elem_size=<optimized out>) at ./malloc/malloc.c:3650
#3 0x0000aaaac67cfa68 in make_string_array (errors=errors@entry=37, v_array=281472912006504) at fork_action.c:47
#4 0x0000aaaac67cfaf4 in action_execve (errors=37, v_config=281472912003024) at fork_action.c:61
#5 0x0000aaaac67cf93c in eio_unix_run_fork_actions (errors=errors@entry=37, v_actions=281472912002960) at fork_action.c:19
The
execveaction allocated the arrays in the forked child process. However, in a multi-threaded program we might have forked while another thread had the malloc lock. In that case, the child would wait forever because it inherited the locked mutex but not the thread that would unlock it. e.g.