Question

我在命令行上的程序崩溃，出现分段错误。

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

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

任何想法/帮助表示感谢。

修改

来自Employed Russian的评论后，

我做'ulimit -c unlimited'来生成核心文件。并将此核心文件作为

解雇gdb

gdb ./my_binary core

我得到了

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实施中崩溃了。这几乎可以肯定是堆损坏（双重释放，释放非malloced，溢出堆分配等）。

Valgrind 应该抓住这个错误并直接指出它。

程序崩溃在gdb下但在valgrind下运行正常

修改

1 个答案: