On 04/29/18 09:55 PM, Milian Wolff wrote: > Hey all. > > I just noticed that one cannot dlopen() libunwind when it is build with -- > enable-per-thread-cache. In such scenarios, dlopen will always fail with > "cannot allocate memory in static TLS block". > > The issue was also encountered by the jemalloc people, see [1] and [2]. > > [1]: https://github.com/jemalloc/jemalloc/issues/937 > [2]: https://github.com/jemalloc/jemalloc/pull/1180 > > The reason for this in libunwind comes from src/dwarf/Gparser.c: > > static __thread struct dwarf_rs_cache tls_cache > __attribute__((tls_model("initial-exec"))); > > The initially specified tls_model("initial-exec") triggers the issue above. > jemalloc has work-arounded this by adding a configure option to remove this > explicit tsl_model setting (cf. [2] above). > > Indeed, just removing the attribute "fixes" libunwind for my use-case in > heaptrack. So the question is now: > > - why was the tls_model explicitly set to initial-exec? > - can we just remove it? > - if not, can we add another configure option similar to what jemalloc did?
As Paul mentioned, it's because __thread and friends aren't async-signal-safe on glibc and may allocate. I'm fine adding a configure-time option to change the tls model if someone wants to provide a patch for it. Facebook has codepaths that try to avoid the trace cache __thread if we actually need async-signal-safety: https://github.com/facebook/folly/blob/cd1bdc912603c0358ba733d379a74ae90ab3a437/folly/experimental/symbolizer/StackTrace.cpp#L31 _______________________________________________ Libunwind-devel mailing list Libunwind-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/libunwind-devel
