LTTng » LTTng-UST

Hi,

After below commit everything just stop working.

commit 48a143c09cc97bf7a2ace811277e7d60b294b5f6 (HEAD -> master, origin/master, origin/HEAD)
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date: Mon Oct 7 15:41:10 2019 -0400

Fix: fd tracker: do not allow signal handlers to close lttng-ust FDs

Split the thread_fd_tracking state from the ust_fd_mutex_nest used to
    track whether a signal handler is nested over a fd tracker lock.

lttng-ust listener threads need to invoke
    lttng_ust_fd_tracker_register_thread() so the fd tracker can
    distinguish them from application threads.

Otherwise, using ust_fd_mutex_nest to try to distinguish between
    ust and application threads makes it possible for signal handlers
    to appear as if they are ust listener threads, and thus attempt to
    close UST file descriptors.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Fixes: #1199

The problem with that commit is that during application starting up, lttng_ust_init constructor will be called.
This will later call lttng_ust_statedump_init, this one will later call lttng_ust_elf_destroy which in turn call close() to close the elf fd.
But at this phase lttng_ust_fd_tracker_register_thread is not called yet because it is only called by ust_listener_thread which is triggered by lttng_ust_init after lttng_ust_statedump_init.
We then misunderstood that this is application close() but not lttng close() and do the normal checking. The checking will be absolutely fail because elf->fd is part of lttng's fds.
Abort() then was called as a consequence.

Note that this happens always and application code actually did not have any chances to execute at all.

/Tai