[lttng-dev] lttng-ust deadlock.

[Aravind HT]

Hi,

I am facing a deadlock in lttng-ust. Though my version is 2.6 I can see
that this is applicable to the the latest UST version also.

Deadlocks happening due to these two flows
1. lttng_fix_pending_events () -> ustcomm_register_event () -> calloc() ->
__GI___dl_iterate_phdr()
     Note that Im not using the libc wrapper, but using a proprietary
version for malloc() family which can call __GI___dl_iterate_phdr() .
     This flow takes up UST_LOCK() before calling __GI___dl_iterate_phdr(),
and __GI___dl_iterate_phdr() has its own mutex( lets say DL_MUTEX).
2. lttng_ust_baddr_statedump() calls  __GI___dl_iterate_phdr() which first
takes up DL_MUTEX and then takes the UST_LOCK() in the call back function
as extract_soinfo_events()->trace_baddr()->UST_LOCK().

Since the order is reversed, it can lead to deadlock. To fix this, do you
think taking UST_LOCK in  lttng_ust_baddr_statedump() ( surrounding
__GI___dl_iterate_phdr()
call ) instead of the call back function is proper ?

In the latest version of UST, I see some changes/refactoring and that the
UST_LOCK has been removed from trace_baddr() and moved one call up, but
still is being called in the call back function after __GI___dl_iterate_phdr()
is called.


Regards,
Aravind.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160623/de2278c7/attachment.html>