LTTng » LTTng-UST

This problem is connected with #1199 in the sense that the root cause is the same.
But for this case, even without doing anything after fork() child process can also end up in deadlock situation.
The problem is because the ust_after_fork_child will try to cleanup the sock_info and will try to lock the same mutex as part of this calling chain.

So we suggest all application that use close() to preload our ust-fd, and application that use fork() to preload our ust-fork(). But doing so, they may end up in a deadlock if both are preloaded.

(gdb) bt
#0 lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007fde70741023 in __GI_pthread_mutex_lock (mutex=mutex@entry=0x7fde70138940 <ust_safe_guard_fd_mutex>) at ../nptl/pthread_mutex_lock.c:78
#2 0x00007fde6fedbeaa in lttng_ust_lock_fd_tracker () at lttng-ust-fd-tracker.c:133
#3 0x00007fde6fed84cd in ustcomm_close_unix_sock (sock=3) at lttng-ust-comm.c:270
#4 0x00007fde6fedc5fd in cleanup_sock_info (sock_info=sock_info@entry=0x7fde70135a20 <global_apps>, exiting=exiting@entry=0) at lttng-ust-comm.c:1046
#5 0x00007fde6fedcac6 in lttng_ust_cleanup (exiting=0) at lttng-ust-comm.c:1834
#6 0x00007fde6fee1f79 in ust_after_fork_child (restore_sigset=0x7fde5dffacb0) at lttng-ust-comm.c:1995
#7 0x00007fde709569c5 in fork () at ustfork.c:53
#8 0x000055f8212cd846 in do_thread ()
#9 0x00007fde7073e6db in start_thread (arg=0x7fde5dffb700) at pthread_create.c:463
#10 0x00007fde7026388f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

/Tai