gdb

    5热度

    1回答

    静态链接二进制文件中缺少调试符号

    我正在使用堆栈构建静态链接二进制文件，并尝试向其添加调试符号（以下内容：https://downloads.haskell.org/~ghc/master/users-guide/debug-info.html）。但是GDB报告：no debugging symbols found。 我缺少什么？ 我已经加入到ghc-options在.cabal file：-g -rtsopts并向ld-opti
    haskell gdb ghc cabal haskell-stack 2017-11-17

    2热度

    1回答

    GDB能否从xx.so解析全局数据而不执行？

    我有一个共享库（hlapi.so）在Linux系统上运行。这hlapi.so有很多模块（我的意思是.c文件）。其中一个被命名为hlapi.c定义这样的两个全球DATAS： static int hlapiInitialized = FALSE; static struct hlapi_data app_sp; 当然也有这个hlapi.c模块在其他许多代码。 hlapi.so发布给基于我们的h
    debugging gcc memory-management gdb core 2017-11-25

    -1热度

    1回答

    为什么mov指令没有正确执行？

    我遇到了一个错误，而调试我的程序，甚至阅读汇编代码 下面是从GDB的图像后，我解决不了，0x4070a1之前，％RDX是0x61b130，并且这个数字应该移到-0x18(%rbp)。但是，在这个指令之后，我发现-0x18(%rbp)变成了0x61b7d0，这让我感到困惑。 由于这个问题，我的程序无法正常运行，谁能告诉我原因？谢谢！ 的C代码： E_enventry t = E_FunEntry(l
    c assembly x86 gdb x86-64 2017-11-25

    -1热度

    1回答

    ERROR “分割故障（核心转储）”

    *Segmentation fault* *mkidir /etc/reaver* 我有一个问题。我有一个操作系统Linux的Fedora 26.我试图与我的网络适配器Alfa Awus036h在Reaver工作。当我运行命令wash -i时，出现此错误：segmentation fault (core dumped)。 文件mkdir /etc/reaver存在。 Аlso驱动wash -i w
    linux gdb coredump 2017-11-25

    0热度

    1回答

    如何从字符串返回gdb.Value（）？

    考虑以下输出相同文本字符串的gdb命令。 (gdb) print foo (gdb) python print(gdb.lookup_symbol('foo')) 在这种情况下，预计gdb.lookup_symbol()返回gdb.Value()实例，它的字符串化等同于默认GDB字串。 但现在考虑以下情况相当于： (gdb) print *&foo 的*&是一个空操作，但试图使用gdb.
    gdb gdb-python 2017-12-03

    2热度

    1回答

    如果GDB条件语法错误

    我在一个文件test.f90有一个非常简单的Fortran程序： program test real :: x x=12 write(*,*) x end program test 我 gfortran -g test.f90 编译它，然后我尝试使用gdb： gdb a.out break 4 if a == 12 但我得到 A syntax erro
    fortran gdb 2017-10-19

    0热度

    2回答

    如何在golang退出前设置断点

    我是一个完整的golang初学者，实际上我正在调试其他人的程序以找出意外退出的原因。 我想知道如何在程序关闭之前调用的“exit”例程中设置断点gdb？ 到目前为止我试过 gdb <program name> run <...wait for program to quit> break 'runtime.goexit' run <...wait for program to break
    debugging go gdb breakpoints exit 2017-10-20

    1热度

    3回答

    核心转储文件中等待的所有线程，但有人触发SIG_ABRT

    我支持用C++编写多年的应用程序，最近它已经开始崩溃，提供我们不知道如何处理的核心转储。 它运行在一个设备上的Ubuntu 14.04.5 当加载在GDB的核心文件，它说： 计划与信号SIGABRT终止，中止 我可以检查230个线程，但他们都在等待（ ）在完全相同的记忆位置。 有一个ID 1的线程，理论上可以是负责任的，但线程也在等待。 所以我基本上有两个问题。 线程的id索引是如何工作的？ GD
    c++ gdb sigabrt 2017-10-20

    0热度

    1回答

    检查由pmap报告的虚拟内存块

    我在程序中看到了泄漏。它不会被“valgrind memcheck”所捕获（我通过总结报告证实了这一点，它不是接近我可以看到的顶级用法）。在使用“valgrind massif - 页面 - 堆 - ”时，我可以更接近我的内存使用情况。 然而，它并没有报告完成追踪的部分，它做了mmap和分配大部分内存，我也无法检查内存分配，因为我只能在程序被终止后才能收集到massif的输出。 我试过的另一件事是
    memory gdb massif 2017-10-20

    1热度

    1回答

    堆栈跟踪中没有函数名称，GDB，但出现在LLDB中

    我正在尝试测试一个Vector类的实现，并试图使用GDB来查看错误发生的位置。 当我用下面gcc -ggdb Vector.c TestVector.c编译，并随后在GDB运行它，我得到以下作为输出（崩溃和试图打印堆栈跟踪后）： | => gdb ./a.out Reading symbols from ./a.out...Reading symbols from /Users/prog/Des
    c macos gdb stack-trace lldb 2017-12-18
最新问题