你们中的一些人可能知道 Google 提供了许多免费的用于分析 c++ 代码的工具： http ://code.google.com/p/google-perftools/
问题是在 64 位上显然存在一些 libunwind 问题，作者无法做任何事情来解决它（
但我预计不会很快修复：这取决于 libc 人员和 libunwind 人员解决一些锁定问题。不幸的是，我们自己无能为力。
)，所以我正在寻找替代品。是否有任何类似的工具可以提供分析数据的酷图形表示（例如
：）
)
编辑：从解释问题的自述文件中粘贴：
2) 在 x86-64 64 位系统上，虽然 tcmalloc 本身工作正常，但 cpu-profiler 工具并不可靠：它有时会工作，但有时会导致段错误。我将首先解释问题，然后是一些解决方法。
请注意，这只影响 cpu-profiler，这是一个 google-perftools 功能，您必须通过设置 CPUPROFILE 环境变量手动打开。如果您不打开 cpu-profiling，您应该不会看到任何由于 perftools 而导致的崩溃。
血淋淋的细节：根本问题出在 backtrace() 函数中，它是 libc 中的内置函数。回溯在正常情况下相当简单，但在必须回溯信号帧时可能会遇到问题。不幸的是，cpu-profiler 使用信号来注册分析事件，因此分析器所做的每个回溯都会跨越一个信号帧。
根据我们的经验，唯一出现问题的情况是信号在 pthread_mutex_lock 中间触发时。pthread_mutex_lock 从系统库中调用了很多，特别是在程序启动和创建新线程时。
解决方案：dwarf 调试格式支持“cfi annotations”，这使得识别信号帧变得容易。一些操作系统发行版，例如 Fedora 和 gentoo 2007.0，已经在它们的 libc 中添加了 cfi 注释。未来版本的 libunwind 应该能够识别这些注释；这些系统不应出现任何崩溃。
解决方法：如果您在运行 cpu-profiler 时发现崩溃问题，请考虑将 ProfilerStart()/ProfilerStop() 插入到您的代码中，而不是设置 CPUPROFILE。这将只分析代码库的那些部分。虽然我们没有做太多测试，但理论上这应该通过将信号生成限制在代码库的一小部分来减少崩溃的机会。理想情况下，您不会在生成新线程的代码周围使用 ProfilerStart()/ProfilerStop()，否则可能会导致调用 pthread_mutex_lock！
--- 2011 年 5 月 17 日