C 如何在Ubuntu中解释GDB回溯日志

C++ How to interpret gdb backtrace log in Ubuntu

本文关键字：解释 GDB 回溯 日志 Ubuntu      更新时间：2023-10-16

我编写了一个相当大的C 程序。作为序言，该程序每次都可以运行良好，除了退出错误，Free（）无效指针通常会导致核心转储。除此之外，该程序每次都需要它需要做的事情。该程序不含任何指针对象或初始化；尽管该程序很长（约3000行），但它是简单的（主要是INT变量，还有一些2D向量数组）。我的第一个想法是，一些用于循环的文章是超越向量界限的编写，所以我运行了Valgrind Mems检查是否存在内存泄漏，但Valgrind返回了一份干净的报告。我的下一个倾向是使用GDB，看看它是否返回任何错误。它确实返回了segabrt，所以我回溯了它，而GDB返回了以下内容，

> #0  0x00007ffff7018c37 in __GI_raise (sig=sig@entry=6)
>     at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff701c028 in __GI_abort () at abort.c:89
> #2  0x00007ffff70552a4 in __libc_message (do_abort=do_abort@entry=1, 
>     fmt=fmt@entry=0x7ffff7167310 "*** Error in `%s': %s: 0x%s ***n")
>     at ../sysdeps/posix/libc_fatal.c:175
> #3  0x00007ffff706182e in malloc_printerr (ptr=<optimized out>, 
>     str=0x7ffff716345e "free(): invalid pointer", action=1) at malloc.c:4998
> #4  _int_free (av=<optimized out>, p=<optimized out>, have_lock=0)
>     at malloc.c:3842
> #5  0x000000000040f152 in __gnu_cxx::new_allocator<int>::deallocate (
>     this=0x7fffff85cf60, __p=0x6c1f40)
>     at /usr/include/c++/4.8/ext/new_allocator.h:110
> #6  0x000000000040ef54 in std::_Vector_base<int, std::allocator<int> >::_M_deallocate (this=0x7fffff85cf60, __p=0x6c1f40, __n=32)
>     at /usr/include/c++/4.8/bits/stl_vector.h:174
> #7  0x000000000040ebc2 in std::_Vector_base<int, std::allocator<int> >::~_Vector_base (this=0x7fffff85cf60, __in_chrg=<optimized out>)
>     at /usr/include/c++/4.8/bits/stl_vector.h:160
> #8  0x000000000040e928 in std::vector<int, std::allocator<int> >::~vector (
>     this=0x7fffff85cf60, __in_chrg=<optimized out>)
>     at /usr/include/c++/4.8/bits/stl_vector.h:416
> #9  0x000000000040e3b5 in main ()

我想我的问题是这个。我该如何解释此回溯？我只看到最后一个堆栈＃9调用主函数，但没有其他错误。我认为堆栈错误＃0-8是所谓的库中的故障？我可以打电话给GDB中的某种方法或某些选项以帮助查明错误以及此回溯中的错误？我一般可以使用GDB的新手，因此对任何建议都将不胜感激。

编辑示例代码：

for(int k = 4; k < 7; k++)
{
    if(TFNCWS[k] == 1)
    {
        TFNCWS[k] = 0;
        TIM[k] = 1;
    }
}

我该如何解释此回溯？

非常简单：您的程序在破坏向量时崩溃，在您的main函数中声明。

最有可能的原因是堆栈腐败。

i运行valgrind mems检查是否有任何内存泄漏

内存泄漏与您的问题无关，而Valgrind在检测堆栈溢出时极为弱。

您应该尝试使用地址消毒剂（在最近的GCC和Clang中可用）。可能会直接指向问题。

相关文章：