On Wednesday, May 2, 2018 4:37:22 PM CEST Dave Watson wrote: > 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.
But there's already the --enable-per-thread-cache option which disables __thread. Isn't that enough for your use case? > Facebook has codepaths that try to avoid the trace cache __thread if > we actually need async-signal-safety: > > https://github.com/facebook/folly/blob/cd1bdc912603c0358ba733d379a74ae90ab3a > 437/folly/experimental/symbolizer/StackTrace.cpp#L31 Cheers -- Milian Wolff [email protected] http://milianw.de _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
