google-perftools

gperftools 2.16 is out!

This release doesn't have major fixes or big headline features, but it has quite a lot of internal modernizations and cleanups. By the number of commits, 2.16 is going to be our biggest release ever.

This release's main focus was making our code and building infrastructure simpler, more straightforward, more portable, and more modern.

Please note that the gperftools 2.16 release will be the last release with the heap leak checker included. The time has come to drop this feature entirely. All users should migrate to relevant gcc/clang sanitizers.

Here are the most notable changes:

• we've upgraded our C++ standard to C++ 17. Some fraction of our code base was modernized.

• We've integrated (vendored copy of) GoogleTest, and most tests now use it. GoogleTest has helped us elimina

gperftools 2.16rc is out!

This release doesn't have major fixes or big headline features, but it has quite a lot of internal modernizations and cleanups. By the number of commits, 2.16 is going to be our biggest release ever.

This release's main focus was making our code and building infrastructure simpler, more straightforward, more portable, and more modern.

Please note that the gperftools 2.16 release will be the last release with the heap leak checker included. The time has come to drop this feature entirely. All users should migrate to relevant gcc/clang sanitizers.

Here are the most notable changes:

• we've upgraded our C++ standard to C++ 17. Some fraction of our code base was modernized.

This release has the following bug fixes:

• Xiaowei Wang has pointed out the pthread linking issue on cmake on older glibcs (where -pthread is not implicit). See #1473 for more details.

• Mikael Simberg and Tom "spot" Callaway have pointed out the missing symbols issue when linking PPC or i386 builds. #1474 has all the details.

Huge thanks to all contributors!

gperftools 2.14 is out!

This release has the following set of notable changes:

• Roman Geissler has contributed a fix to nasty initialization bug introduced in 2.13 (see github issue #1452 for one example where it fails).

• spinlock delay support now has proper windows support. Instead of simply sleeping, it uses WaitOnAddress (which is basically windows equivalent of futexes). This improvement was contributed by Lennox Ho.

• we now have basic QNX support (basic malloc + heap profiler) championed by Xiang.Lin. Thanks! Do note, however, that QNX doesn't provide SIGPROF ticks, so there will be no cpu profiler support on this OS.

• Yikai Zhao has contributed several fixes to important corner cases of generic_fp stacktrace method.

• several people have contributed v

Brett T. Warden contributed one significant fix. After a change in the previous release, we installed broken pkg-config files. Brett noticed and fixed that. Huge thanks!

gperftools 2.13 is out!

This release includes a few minor fixes:

• Ivan Dlugos has fixed some issues with cmake and config.h defines.

• 32-bit builds no longer require 64-bit atomics (which we wrongly introduced in 2.11 and which broke builds on some 32-bit architectures).

• generic_fp backtracing method now uses robust address probing method. The previous approach had occasional false positives, which caused occasional rare crashes.

• In some cases, MSVC generated TrivialOnce machine code that deadlocked programs on startup. The issue is now fixed.

30 May 2022

gperftools 2.10 is out!

Here are notable changes:

• Matt T. Proud contributed documentation fix to call Go programming language by it's true name instead of golang.
• Robert Scott contributed debugallocator feature to use readable (PROT_READ) fence pages. This is activated by TCMALLOC_PAGE_FENCE_READABLE environment veriable.
• User stdpain contributed fix for cmake detection of libunwind.
• Natale Patriciello contributed fix for OSX Monterey support.
• Volodymyr Nikolaichuk contributed support for returning memory back to OS by using mmap with MAP_FIXED and PROT_NONE. It is off by default and enabled by preprocessor define: FREE_MMAP_PROT_NONE. This should help OSes that don't support Linux-style madvise MADV_DONTNEED or BSD-style MADV_FREE.
• Jingyun Hua has contributed basic support for LoongArc