https://bugs.kde.org/show_bug.cgi?id=509666
--- Comment #3 from Paul Floyd <[email protected]> --- Can you get a stacktrace from Valgrind when it hangs? Can you also get file/line numbers for the tcmalloc stacktrace? This is happening somewhere in the tcmalloc startup code. https://github.com/gperftools/gperftools/blob/80cdbea9a9be8d0541a162cb6bc9d2119c34d913/src/malloc_extension.cc#L331 I assume here that the std::atomic::load() will succeed (this region is bound to be monothreaded). I also guess here that inst is nullptr on the first call. The tc_free(tc_malloc(32)) should be using Valgrind's replacement functions (the tc_xxx functions are weak aliases). Then it recursively calls itself. On the second call inst ought not be nullptr and it should be returned. Nothing there stands out to me as the cause of a hang. Have you opened an issue with gperftools? This is likely to be a regression on their side. At work we've been using an old version of tcmalloc (2.5.93) for years. -- You are receiving this mail because: You are watching all bug changes.
