【问题标题】：glog library (google log) printing out `(unknown)` in stacktrace?glog 库（谷歌日志）在堆栈跟踪中打印出“（未知）”？
【发布时间】：2019-05-19 13:04:27
【问题描述】：

glog 库正在为堆栈跟踪中的某些堆栈帧打印 (unknown)。

我在 Ubuntu 18.04 上使用标准的 libgoogle-glog-dev 包：

$ cat > t.cc
#include <glog/logging.h>
void h() { LOG(FATAL) << "test"; }
void g() { h(); }
void f() { g(); }
int main(int argc, char** argv) {
  google::InitGoogleLogging(argv[0]);
  f();
}
^D

上述程序编译时...

$ g++ t.cc -lglog

...然后运行...

$ ./a.out

...输出以下内容：

F1219 13:54:46.608317 13408 t.cc:3] test
*** Check failure stack trace: ***
    @     0x7f90ddd970cd  google::LogMessage::Fail()
    @     0x7f90ddd98f33  google::LogMessage::SendToLog()
    @     0x7f90ddd96c28  google::LogMessage::Flush()
    @     0x7f90ddd99999  google::LogMessageFatal::~LogMessageFatal()
    @     0x56279a0a7b30  (unknown)
    @     0x56279a0a7b45  (unknown)
    @     0x56279a0a7b51  (unknown)
    @     0x56279a0a7b77  (unknown)
    @     0x7f90dd632b97  __libc_start_main
    @     0x56279a0a79fa  (unknown)
Aborted (core dumped)

查看带有(unknown) 的框架 - 我希望它们能够读取main、f、g、h

我已尝试添加 -rdynamic，但我仍然观察到相同的行为：

 $ g++ t.cc -lglog -rdynamic

我已尝试添加 -g，但我仍然观察到相同的行为：

 $ g++ t.cc -lglog -o t -g -rdynamic

【问题讨论】：

对于其他人，在 repo 上也有一个相关的 GitHub 问题（由同一作者）：github.com/google/glog/issues/409
如果我正确理解了这个问题，我不是 100%。你描述你看到的和你期望的。您想要一种查看函数名称的方法吗？如果是这样，请看看我的回答。否则请帮助我更好地理解这个问题。

标签： c++ linux logging glog

【解决方案1】：

我刚刚尝试过，它对我有用。
我可以看到 h()、g()、f() 的结果显示在堆栈跟踪中。

F1219 16:20:16.171772 20931 main.cpp:2] test
*** Check failure stack trace: ***
    @     0x7f951ee03e6d  (unknown)
    @     0x7f951ee05ced  (unknown)
    @     0x7f951ee03a5c  (unknown)
    @     0x7f951ee0663e  (unknown)
    @           0x40089a  h()
    @           0x4008af  g()
    @           0x4008bb  f()
    @           0x4008e1  main
    @     0x7f951e22e3d5  __libc_start_main
    @           0x4007a9  (unknown)

Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

这是我的 CMakeLists.txt 文件

cmake_minimum_required(VERSION 3.13)
project(test_glog)

set(CMAKE_CXX_STANDARD 14)

include_directories(/usr/include)
link_libraries(glog)
add_executable(test_glog main.cpp)

当我编译时扩展为：

我在 CentOS 7 上并安装了以下库：

yum install glog-devel gflags-devel

这是我的构建方式：

[user@cent1 build]$ make VERBOSE=1
/usr/bin/cmake3 -H/home/user/CLionProjects/test_glog -B/home/user/CLionProjects/test_glog/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake3 -E cmake_progress_start /home/user/CLionProjects/test_glog/build/CMakeFiles /home/user/CLionProjects/test_glog/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/user/CLionProjects/test_glog/build'
make -f CMakeFiles/test_glog.dir/build.make CMakeFiles/test_glog.dir/depend
make[2]: Entering directory `/home/user/CLionProjects/test_glog/build'
cd /home/user/CLionProjects/test_glog/build && /usr/bin/cmake3 -E cmake_depends "Unix Makefiles" /home/user/CLionProjects/test_glog /home/user/CLionProjects/test_glog /home/user/CLionProjects/test_glog/build /home/user/CLionProjects/test_glog/build /home/user/CLionProjects/test_glog/build/CMakeFiles/test_glog.dir/DependInfo.cmake --color=
make[2]: Leaving directory `/home/user/CLionProjects/test_glog/build'
make -f CMakeFiles/test_glog.dir/build.make CMakeFiles/test_glog.dir/build
make[2]: Entering directory `/home/user/CLionProjects/test_glog/build'
[ 50%] Building CXX object CMakeFiles/test_glog.dir/main.cpp.o
/opt/rh/devtoolset-7/root/usr/bin/c++    -std=gnu++14 -o CMakeFiles/test_glog.dir/main.cpp.o -c /home/user/CLionProjects/test_glog/main.cpp
[100%] Linking CXX executable test_glog
/usr/bin/cmake3 -E cmake_link_script CMakeFiles/test_glog.dir/link.txt --verbose=1
/opt/rh/devtoolset-7/root/usr/bin/c++     CMakeFiles/test_glog.dir/main.cpp.o  -o test_glog -lglog 
make[2]: Leaving directory `/home/user/CLionProjects/test_glog/build'
[100%] Built target test_glog
make[1]: Leaving directory `/home/user/CLionProjects/test_glog/build'
/usr/bin/cmake3 -E cmake_progress_start /home/user/CLionProjects/test_glog/build/CMakeFiles 0

更新：我在 vm 中安装 Debian ubuntu-18.04.1-desktop-amd64.iso 并从源代码构建 glog。您的示例现在显示：

$ ./a.out 
F0102 23:54:15.603329 10358 t.cc:2] test
*** Check failure stack trace: ***
    @     0x55c930b28d2c  google::LogMessage::Fail()
    @     0x55c930b28c74  google::LogMessage::SendToLog()
    @     0x55c930b285b5  google::LogMessage::Flush()
    @     0x55c930b2be66  google::LogMessageFatal::~LogMessageFatal()
    @     0x55c930b25820  google::thread_msg_data
    @     0x55c930b25835  google::thread_msg_data
    @     0x55c930b25841  google::thread_msg_data
    @     0x55c930b25867  google::thread_msg_data
    @     0x7ff9fbf2eb97  __libc_start_main
    @     0x55c930b256ea  google::thread_msg_data
    @              (nil)  (unknown)
Aborted (core dumped)

我可以看到我们正在尝试解决此问题，因此我建议您打开一个问题格洛格。 https://github.com/google/glog/pull/347/commits/26459400f49850bda8e736882c6f22c2ce766761

我还尝试直接从命令链接构建它并显示设置。不确定构建 glog 库的设置是否会产生影响。

$ g++ t.cc -lglog --verbose
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE t.cc -quiet -dumpbase t.cc -mtune=generic -march=x86-64 -auxbase t -version -fstack-protector-strong -Wformat -Wformat-security -o /tmp/ccoFCYTb.s
GNU C++14 (Ubuntu 7.3.0-27ubuntu1~18.04) version 7.3.0 (x86_64-linux-gnu)
    compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/7
 /usr/include/x86_64-linux-gnu/c++/7
 /usr/include/c++/7/backward
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++14 (Ubuntu 7.3.0-27ubuntu1~18.04) version 7.3.0 (x86_64-linux-gnu)
    compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1bfae38ae5df64de6196cbd8c3b07d86
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccvUzQBB.o /tmp/ccoFCYTb.s
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=/tmp/ccNEOWk1.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. /tmp/ccvUzQBB.o -lglog -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'

这是我运行它时的输出：

$ ./a.out 
F0106 12:07:11.753652 28547 t.cc:2] test
*** Check failure stack trace: ***
    @     0x55c500dedd2c  google::LogMessage::Fail()
    @     0x55c500dedc74  google::LogMessage::SendToLog()
    @     0x55c500ded5b5  google::LogMessage::Flush()
    @     0x55c500df0e66  google::LogMessageFatal::~LogMessageFatal()
    @     0x55c500dea820  google::thread_msg_data
    @     0x55c500dea835  google::thread_msg_data
    @     0x55c500dea841  google::thread_msg_data
    @     0x55c500dea867  google::thread_msg_data
    @     0x7f882d938b97  __libc_start_main
    @     0x55c500dea6ea  google::thread_msg_data
    @              (nil)  (unknown)
Aborted (core dumped)

更新 2： glog 开发人员 Evgeny Prigorodov 一直在研究这个问题并确定了这个问题。我相信这个问题很快就会得到解决。

下面是 src/symbolize.cc 在 a93a451 之后发生的情况：

堆栈跟踪中的每一行都在函数 SymbolizeAndDemangle() 中进行准备。它计算变量 start_address / base_address 并调用函数 GetSymbolFromObjectFile()，该函数尝试查找与给定帧指令指针 (pc) 对应的符号。

在 v0.3.4 中，对 GetSymbolFromObjectFile() 的调用传递了 start_address 的值，即内存区域的起始地址，它永远不能为零。 GetSymbolFromObjectFile() 没有检查 start_address 的值，只是用它在两个符号表中查找。

在 v0.3.5 中，对 GetSymbolFromObjectFile() 的调用开始传递 base_address 的值。如果在第一个内存区域内找到了帧程序计数器并且可执行映像已以零偏移量映射，则该值可能会变为零。这似乎是一种常见的情况。

GetSymbolFromObjectFile() 中的另一个更改添加了符号偏移调整代码和新检查：如果在所有调整后 symbol_offset 等于零，则该函数返回一个失败值，意思是“未找到符号”。由于 symbol_offset 变量是从 base_address 计算出来的，因此这种情况很可能发生。

欲知详情see

【讨论】：

如果你执行我在问题中给出的命令会发生什么？即不使用cmake，而是使用g++ t.cc -lglog -o t -g -rdynamic 和./a.out 手动编译/链接/运行？
当我使用 cmake（在 Ubuntu 18.04 上）构建测试时，我观察到与问题相同的问题。看起来问题是 Ubuntu 特有的？
@AndrewTomazos 我尝试在命令行上编译它，它仍然有效。 gcc main.cpp -o t -g -rdynamic -lglog -lstdc++
如果它在 CentOS 7 上工作，必须是 Ubuntu 特定的东西。如果没有人知道，我想我需要从源代码构建 glog 并对其进行调试以弄清楚堆栈跟踪机制/符号化发生了什么.
CXXFLAGS 环境变量设置为什么？

【解决方案2】：

这似乎是this commit 在 glog v0.3.5 中引入的回归。

示例代码在 Ubuntu 16.04 中使用股票版本 libgoogle-glog-dev v0.3.4 编译时可以正常工作

并且该问题可以在 AWS Ubuntu Server 18.04（AMI ID ami-00035f41c82244dab）上以libgoogle-glog-dev v0.3.5 的股票版本可靠地重现。

将包 libgoogle-glog-dev 降级到版本 v0.3.4 修复了 Ubuntu 18.04 上的问题。

要降级版本，请应用以下解决方法：1) 使用以前的版本添加 Xenial 存储库，以及 2) 使 apt 更喜欢 libgoogle-glog-dev 的 0.3.4 版本（又名 package pinning）：

ubuntu@ec-ubuntu18:~$ dpkg -l | grep glog
ii  libgoogle-glog-dev               0.3.5-1                           amd64        library that implements application-level logging.
ii  libgoogle-glog0v5                0.3.5-1                           amd64        library that implements application-level logging.

ubuntu@ec-ubuntu18:~$ ./a.out 
F0108 19:22:08.617049 19750 t.cc:2] test
*** Check failure stack trace: ***
    @     0x7ffa821240cd  google::LogMessage::Fail()
    @     0x7ffa82125f33  google::LogMessage::SendToLog()
    @     0x7ffa82123c28  google::LogMessage::Flush()
    @     0x7ffa82126999  google::LogMessageFatal::~LogMessageFatal()
    @     0x563949dd89c0  (unknown)
    @     0x563949dd89d5  (unknown)
    @     0x563949dd89e1  (unknown)
    @     0x563949dd8a07  (unknown)
    @     0x7ffa819bfb97  __libc_start_main
    @     0x563949dd888a  (unknown)
Aborted (core dumped)

ubuntu@ec-ubuntu18:~$ echo "deb http://archive.ubuntu.com/ubuntu/ xenial universe" | sudo tee /etc/apt/sources.list.d/xenial.list
ubuntu@ec-ubuntu18:~$ cat << EOF | sudo tee /etc/apt/preferences.d/libgoogle-glog-dev
# Pin down the version of google-glog
Package: libgoogle-glog-dev libgoogle-glog0v5
Pin: version 0.3.4*
Pin-Priority: 1000

# Make sure that other packages from Xenial cannot be installed
Package: *
Pin: release v=16.04, l=Ubuntu
Pin-Priority: -10
EOF

ubuntu@ec-ubuntu18:~$ sudo apt-get update
ubuntu@ec-ubuntu18:~$ sudo apt-get upgrade libgoogle-glog-dev

ubuntu@ec-ubuntu18:~$ dpkg -l | grep glog
ii  libgoogle-glog-dev               0.3.4-0.1                         amd64        library that implements application-level logging.
ii  libgoogle-glog0v5                0.3.4-0.1                         amd64        library that implements application-level logging.

ubuntu@ec-ubuntu18:~$ ./a.out 
F0108 19:30:42.793792 19518 t.cc:2] test
*** Check failure stack trace: ***
    @     0x7f3da453f5cd  google::LogMessage::Fail()
    @     0x7f3da4541433  google::LogMessage::SendToLog()
    @     0x7f3da453f15b  google::LogMessage::Flush()
    @     0x7f3da4541e1e  google::LogMessageFatal::~LogMessageFatal()
    @     0x5625c9e069c0  h()
    @     0x5625c9e069d5  g()
    @     0x5625c9e069e1  f()
    @     0x5625c9e06a07  main
    @     0x7f3da3ddbb97  __libc_start_main
    @     0x5625c9e0688a  _start
Aborted (core dumped)

我已检查恢复源包的 lines 359 和 806 中的提交更改也可以解决 Ubuntu 18.04 上的问题。

【讨论】：

【解决方案3】：

我可以得到相同的输出，并找到了一个解决方法来查看函数名称。

我可以在 ubuntu 18.10 上重现你的问题，我也得到这个输出：

    2019-01-07 22:55:59 joerg@dilbert:~/src/tmp/so5$ ./a.out 
F0107 22:56:02.115654 23819 t.cc:2] test
*** Check failure stack trace: ***
    @     0x7f15c11410cd  google::LogMessage::Fail()
    @     0x7f15c1142f33  google::LogMessage::SendToLog()
    @     0x7f15c1140c28  google::LogMessage::Flush()
    @     0x7f15c1143999  google::LogMessageFatal::~LogMessageFatal()
    @     0x560617c379c0  (unknown)
    @     0x560617c379d5  (unknown)
    @     0x560617c379e1  (unknown)
    @     0x560617c37a07  (unknown)
    @     0x7f15c09dcb97  __libc_start_main
    @     0x560617c3788a  (unknown)
Aborted (core dumped)

解决方法

使用 valgrind！

但是，当我使用 valgrind 时，我会看到实际的函数名称：

2019-01-07 22:56:02 joerg@dilbert:~/src/tmp/so5$ valgrind ./a.out 
==32384== Memcheck, a memory error detector
==32384== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==32384== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==32384== Command: ./a.out
==32384== 
F0107 22:56:58.129938 32384 t.cc:2] test
==32384== Syscall param msync(start) points to uninitialised byte(s)
==32384==    at 0x5511B24: msync (msync.c:25)
==32384==    by 0x5A102F3: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==32384==    by 0x5A14230: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==32384==    by 0x5A1453E: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==32384==    by 0x5A14A98: ??? (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==32384==    by 0x5A10E70: _ULx86_64_step (in /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1)
==32384==    by 0x4E50F4A: ??? (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==32384==    by 0x4E4809B: google::LogMessage::RecordCrashReason(google::glog_internal_namespace_::CrashReason*) (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==32384==    by 0x4E49E94: google::LogMessage::SendToLog() (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==32384==    by 0x4E47C27: google::LogMessage::Flush() (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==32384==    by 0x4E4A998: google::LogMessageFatal::~LogMessageFatal() (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==32384==    by 0x1089BF: h() (t.cc:2)
==32384==  Address 0x1ffefff000 is on thread 1's stack
==32384== 
*** Check failure stack trace: ***
    @          0x4e480cd  google::LogMessage::Fail()
    @          0x4e49f33  google::LogMessage::SendToLog()
    @          0x4e47c28  google::LogMessage::Flush()
    @          0x4e4a999  google::LogMessageFatal::~LogMessageFatal()
    @           0x1089c0  (unknown)
    @           0x1089d5  (unknown)
    @           0x1089e1  (unknown)
    @           0x108a07  (unknown)
    @          0x5417b97  __libc_start_main
    @           0x10888a  (unknown)
==32384== 
==32384== Process terminating with default action of signal 6 (SIGABRT)
==32384==    at 0x5434E97: raise (raise.c:51)
==32384==    by 0x5436800: abort (abort.c:79)
==32384==    by 0x4E514E6: ??? (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==32384==    by 0x4E480CC: google::LogMessage::Fail() (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==32384==    by 0x4E49F32: google::LogMessage::SendToLog() (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==32384==    by 0x4E47C27: google::LogMessage::Flush() (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==32384==    by 0x4E4A998: google::LogMessageFatal::~LogMessageFatal() (in /usr/lib/x86_64-linux-gnu/libglog.so.0.0.0)
==32384==    by 0x1089BF: h() (t.cc:2)
==32384==    by 0x1089D4: g() (t.cc:3)
==32384==    by 0x1089E0: f() (t.cc:4)
==32384==    by 0x108A06: main (t.cc:7)
==32384== 
==32384== HEAP SUMMARY:
==32384==     in use at exit: 10,949 bytes in 191 blocks
==32384==   total heap usage: 238 allocs, 47 frees, 111,825 bytes allocated
==32384== 
==32384== LEAK SUMMARY:
==32384==    definitely lost: 0 bytes in 0 blocks
==32384==    indirectly lost: 0 bytes in 0 blocks
==32384==      possibly lost: 0 bytes in 0 blocks
==32384==    still reachable: 10,949 bytes in 191 blocks
==32384==         suppressed: 0 bytes in 0 blocks
==32384== Rerun with --leak-check=full to see details of leaked memory
==32384== 
==32384== For counts of detected and suppressed errors, rerun with: -v
==32384== Use --track-origins=yes to see where uninitialised values come from
==32384== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)
Aborted (core dumped)

您在开始时看到与以前相同的输出，最后有一个堆栈跟踪函数名称。这有帮助吗？

我用它来编译和链接它：

g++ t.cc -lglog

so：没有特殊的编译器或链接器标志。

这些是 g++ 和 valgrind 版本：

2019-01-07 23:01:45 joerg@dilbert:~/src/tmp/so5$ g++ --version
g++ (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

2019-01-07 23:01:49 joerg@dilbert:~/src/tmp/so5$ valgrind --version
valgrind-3.13.0

【讨论】：

感谢您的解决方法，但我想让堆栈跟踪在正常运行时工作。看起来这是一个 glog 错误。希望有一天 glog 的一些人会去看看它，或者社区中的某个人（可能是我）可以调试它并在某个时候修复它。