[lttng-dev] lttng-ust deadlock.

[Mathieu Desnoyers]

Hi, 

LTTng-UST 2.6 is end of life. Please upgrade to a new version. 

Thanks, 

Mathieu 

----- On Jun 23, 2016, at 2:03 AM, Aravind HT <aravind.ht at gmail.com> wrote: 

> 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.

> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20160623/b8a71ec0/attachment.html>