无法分析多线程应用程序的核心转储问题............（需要帮助）答案

【问题标题】：Not to Able analayze the Core dump issue for Multithreaded application.........(Help Required)无法分析多线程应用程序的核心转储问题............（需要帮助）
【发布时间】：2011-01-19 16:16:48
【问题描述】：

我正在开发多线程应用程序，当进程转储时它总是生成核心，如下所示，我无法理解它实际转储的位置。

GNU gdb Red Hat Linux (6.5-25.el5rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".


warning: exec file is newer than core file.
Core was generated by `multithreadprocess                                                                       '.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000448f7a in std::ostream::operator<< ()
(gdb) where
0x000000000044bd32 in std::ostream::operator<< ()
#1  0x0000000000450b21 in std::ostream::operator<< ()
#2  0x000000000042eda9 in std::string::operator= ()
#3  0x00000030582062e7 in start_thread () from /lib64/libpthread.so.0
#4  0x00000030576ce3bd in clone () from /lib64/libc.so.6

(gdb)thread apply all bt 
Thread 6 (process 11674):
#0  0x000000305820a687 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000431140 in std::string::operator= ()
#2  0x00000030582062e7 in start_thread () from /lib64/libpthread.so.0
#3  0x00000030576ce3bd in clone () from /lib64/libc.so.6

Thread 5 (process 11683):
#0  0x000000305820cbfb in write () from /lib64/libpthread.so.0
#1  0x0000000000449151 in std::ostream::operator<< ()
#2  0x000000000043b74a in std::string::operator= ()
#3  0x000000000046c3f4 in std::string::substr ()
#4  0x000000000046e3c1 in std::string::substr ()
#5  0x00000000004305a4 in std::string::operator= ()
#6  0x00000030582062e7 in start_thread () from /lib64/libpthread.so.0
#7  0x00000030576ce3bd in clone () from /lib64/libc.so.6

Thread 4 (process 11744):
#0  0x00000030576c5896 in poll () from /lib64/libc.so.6
#1  0x0000000000474f1c in std::string::substr ()
#2  0x000000000043b889 in std::string::operator= ()
#3  0x0000000000474dbc in std::string::substr ()
#4  0x00000000004306a5 in std::string::operator= ()
#5  0x00000030582062e7 in start_thread () from /lib64/libpthread.so.0
#6  0x00000030576ce3bd in clone () from /lib64/libc.so.6

Thread 3 (process 11864):
#0  0x000000305820a687 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000431140 in std::string::operator= ()
#2  0x00000030582062e7 in start_thread () from /lib64/libpthread.so.0
#3  0x00000030576ce3bd in clone () from /lib64/libc.so.6

Thread 2 (process 11866):
#0  0x000000305820a687 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x0000000000431140 in std::string::operator= ()
#2  0x00000030582062e7 in start_thread () from /lib64/libpthread.so.0
#3  0x00000030576ce3bd in clone () from /lib64/libc.so.6

Thread 1 (process 11865):
#0  0x000000000044bd32 in std::ostream::operator<< ()
#1  0x0000000000450b21 in std::ostream::operator<< ()
#2  0x000000000042eda9 in std::string::operator= ()
#3  0x00000030582062e7 in start_thread () from /lib64/libpthread.so.0
#4  0x00000030576ce3bd in clone () from /lib64/libc.so.6

如果我给 bt full 它是这样显示的

(gdb) bt full
#0  0x000000000044bd32 in std::ostream::operator<< ()
No symbol table info available.
#1  0x0000000000450b21 in std::ostream::operator<< ()
No symbol table info available.
#2  0x000000000042eda9 in std::string::operator= ()
No symbol table info available.
#3  0x00000030582062e7 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4  0x00000030576ce3bd in clone () from /lib64/libc.so.6
No symbol table info available.

【问题讨论】：

注意：“警告：exec 文件比核心文件新。”您最好使用当前拥有的可执行文件重新运行。
所有列出的行看起来都来自标准库 - 我建议使用符号重新编译代码，并重现崩溃，如果可能的话直接在 gdb 中。

标签： linux multithreading gdb core rhel5

【解决方案1】：

在我看来，您在没有适当标志的多线程应用程序中使用 iostream。见this。特别要注意它说的是

当您构建一个应用程序时使用 libC 的 iostream 类在多线程中运行的库环境，编译和链接应用程序的源代码使用 -mt 选项。此选项通过 -D_REENTRANT 到预处理器，-lthread 到链接器。

这是针对特定平台的；您的要求可能会有所不同。

【讨论】：

在 Linux 上，-D_REENTRANT 主要是一个空操作，不太可能与问题有关。

【解决方案2】：

GDB 6.5 已经很老了。您可能会从（当前）GDB 7.0.1 获得明显更好的堆栈跟踪。

您似乎也在尝试调试优化的代码，构建时没有 -g 标志，并且您可能没有调试正确的可执行文件（GDB 警告您的可执行文件比您的核心更新）。

确保您的可执行文件和所有在info shared GDB 输出中列出的库完全在生成您的内核的系统之间匹配以及您正在分析核心的系统（如果它们不一样）——这是最重要的——如果不匹配，你可能会得到虚假的堆栈跟踪（和堆栈你发布的痕迹在我看来完全是假的）。

【讨论】：