https://bugs.kde.org/show_bug.cgi?id=507186
--- Comment #7 from Vorpal <[email protected]> --- > Can you create an MWE that would allow me to reproduce the issue? I'm very > reluctant in adopting your proposed solution without having a way to test it. I fully understand it, my code was a quick hack to fix my immediate problem. I was not entirely happy with it myself. Since your simple solution worked, this is presumably not needed? I could still try, but I observed this on a million lines C++ code base with hundreds of shared libraries, it might not be trivial to create a reproducer. > what platform are you on? Kubuntu 24.04 as of the initial report and still as of writing this. > is your app maybe doing something funky with tls storage, cf. > https://www.akkadia.org/drepper/tls.pdf ? Good question, and quite possible in some dependency or other. We only seem to have one thread_local in our own code, but I see that we have dependencies (for example rxcpp, rapidjson, spdlog and grpc) that use thread locals internally. My *guess* of what is going on is that glibc needed to expand it's backing storage for TLS variables. I remember reading somewhere (last year, so don't remember where exactly) that by default glibc has a static block of memory for TLS bookkeeping, enough for 32 (non-initial-exec) variables. If any more are needed, glibc uses malloc to allocate a new chunk. What then happened was likely that heaptrack's allocation tipped it over, causing the new allocation. So a very specific combination of unlucky circumstances. -- You are receiving this mail because: You are watching all bug changes.
