程序在 gdb 下崩溃，但在 valgrind 下运行良好

Question

我的命令行程序因分段错误而崩溃。

我限制了堆栈大小并再次运行程序并生成核心文件以调查问题的位置。然后在 gdb 下我试图调查原因，但这并没有太大帮助，因为代码似乎在外部库调用时崩溃，这是一个 Fortran 库，我从 C++ 调用 C 接口。

但是，同样的程序在 valgrid 下运行时不会崩溃。我想我在某处有内存泄漏，但也许其他人以前也经历过这种情况。但如果我有内存泄漏，valgrid 也应该检测到它。

任何想法/帮助表示赞赏。

编辑

在雇佣俄罗斯人的cmets之后，

我做了'ulimit -c unlimited' 来生成核心文件。并用这个核心文件触发 gdb

gdb ./my_binary 核心

我得到了

GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/utabak/thesis/C++/numericTests/symmetric_solver_test/symmetric_level1...done.

warning: core file may not match specified executable file.
[New LWP 18769]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./symmetric_level1'.
Program terminated with signal 11, Segmentation fault.
#0  _int_malloc (av=0x2af4a23cf720, bytes=4600) at malloc.c:3865
3865    malloc.c: No such file or directory.
(gdb) x/i $pc
=> 0x2af4a2096c2b <_int_malloc+2363>:   mov    %rdx,(%rax,%rdx,1)
(gdb) where
#0  _int_malloc (av=0x2af4a23cf720, bytes=4600) at malloc.c:3865
#1  0x00002af4a2098f95 in __GI___libc_malloc (bytes=4600) at malloc.c:2924
#2  0x00002af49db3459f in for__spec_align_alloc () from /home/utabak/external_libraries/intel/composer_xe_2013.0.079/compiler/lib/intel64/libifcore.so.5
#3  0x00002af49db34411 in for_allocate () from /home/utabak/external_libraries/intel/composer_xe_2013.0.079/compiler/lib/intel64/libifcore.so.5
#4  0x00000000004c21a4 in dmumps_301_ ()
#5  0x0000000000516e6c in dmumps_ ()
#6  0x000000000043cf91 in dmumps_f77_ ()
#7  0x000000000041beb9 in dmumps_c ()
#8  0x0000000000410dac in Solvers::LinearSolverMumps::solve (this=0x3, B=..., X=...) at /home/utabak/thesis/C++_Repos/vibrosys/src/LinearSolverMumps.cc:377
#9  0x000000000040cdb5 in main (argc=3, argv=0xe644f0) at symmetric_level1.cc:253

使用 Valgrind 输出更新

*dmumps_c 是被调用的函数*

==29798== Conditional jump or move depends on uninitialised value(s)
==29798==    at 0x41BA25: dmumps_c (in /home/utabak/thesis/C++/numericTests/symmetric_solver_test/symmetric_level1)
==29798==    by 0x411066: Solvers::LinearSolverMumps::~LinearSolverMumps() (LinearSolverMumps.cc:420)
==29798==    by 0x40D676: main (symmetric_level1.cc:329)
==29798== 
==29798== Use of uninitialised value of size 8
==29798==    at 0x41BA2C: dmumps_c (in /home/utabak/thesis/C++/numericTests/symmetric_solver_test/symmetric_level1)
==29798==    by 0x411066: Solvers::LinearSolverMumps::~LinearSolverMumps() (LinearSolverMumps.cc:420)
==29798==    by 0x40D676: main (symmetric_level1.cc:329)
==29798== 
==29798== Use of uninitialised value of size 8
==29798==    at 0x41BA35: dmumps_c (in /home/utabak/thesis/C++/numericTests/symmetric_solver_test/symmetric_level1)
==29798==    by 0x411066: Solvers::LinearSolverMumps::~LinearSolverMumps() (LinearSolverMumps.cc:420)
==29798==    by 0x40D676: main (symmetric_level1.cc:329)
==29798== 
==29798== Conditional jump or move depends on uninitialised value(s)
==29798==    at 0x41BA42: dmumps_c (in /home/utabak/thesis/C++/numericTests/symmetric_solver_test/symmetric_level1)
==29798==    by 0x411066: Solvers::LinearSolverMumps::~LinearSolverMumps() (LinearSolverMumps.cc:420)
==29798==    by 0x40D676: main (symmetric_level1.cc:329)
==29798== 
==29798== Use of uninitialised value of size 8
==29798==    at 0x41BA42: dmumps_c (in /home/utabak/thesis/C++/numericTests/symmetric_solver_test/symmetric_level1)
==29798==    by 0x411066: Solvers::LinearSolverMumps::~LinearSolverMumps() (LinearSolverMumps.cc:420)
==29798==    by 0x40D676: main (symmetric_level1.cc:329)
==29798== 
==29798== 
==29798== HEAP SUMMARY:
==29798==     in use at exit: 3,289,886 bytes in 16 blocks
==29798==   total heap usage: 294,609 allocs, 294,593 frees, 864,048,760 bytes allocated
==29798== 
==29798== LEAK SUMMARY:
==29798==    definitely lost: 0 bytes in 0 blocks
==29798==    indirectly lost: 0 bytes in 0 blocks
==29798==      possibly lost: 0 bytes in 0 blocks
==29798==    still reachable: 3,289,886 bytes in 16 blocks
==29798==         suppressed: 0 bytes in 0 blocks
==29798== Reachable blocks (those to which a pointer was found) are not shown.
==29798== To see them, rerun with: --leak-check=full --show-reachable=yes
==29798== 
==29798== For counts of detected and suppressed errors, rerun with: -v
==29798== Use --track-origins=yes to see where uninitialised values come from
==29798== ERROR SUMMARY: 18220 errors from 158 contexts (suppressed: 2 from 2)

Answer 1

我限制了堆栈大小并再次运行程序并生成核心文件以调查问题的位置。

如果您的新有限堆栈太小，您可能引入了一个全新且不相关的问题。

调用外部库时崩溃

太小的堆栈大小很容易做到这一点。

然而，同样的程序在 valgrid 下运行而不会崩溃。

Valgrind 是否报告任何错误？如果是，请修复它们。如果不是，请注意 Valgrind 可能会更改执行环境或时间以充分隐藏问题。

我想我的某个地方有内存泄漏

内存泄漏很少导致程序崩溃。

您调试此问题的方法似乎全错了。你似乎在“调试by coincidence”。

与其改变问题的“随机”部分，不如试着去理解它。第一步：尝试让程序创建一个core 文件而不更改任何其他内容（设置ulimit -c unlimited 除外）。

一旦你有了core，看看崩溃在哪里。如果您无法理解所看到的内容，请再次询问，但请提供详细信息（where 和 x/i $pc 命令的 gdb 输出会有所帮助）。

更新

你在malloc 实现中崩溃了。这几乎肯定是堆损坏的迹象（双重释放、释放非分配的、溢出的堆分配等）

Valgrind应该发现这个错误并直接指出它。