我正在尝试从控制台开始调试我的应用程序。>gdb./Geod然后在gdb中(gdb)run我得到了输出:errorwhileloadingsharedlibraries:libGeo.Cored.so.1:cannotopensharedobjectfile:Nosuchfileordirectory系统配置如下:>echo$LD_LIBRARY_PATH/home/paceholder/projects/geo/lib/debug>ls$LD_LIBRARY_PATHlibGeo.Cored.so.1.0.0libGeo.Cored.solibGeo.Cored.so.1libGeo
我不是专业的C程序员。我在使用GDB调试程序时遇到问题。(我试图修复的错误与我在这里询问的问题无关。)我的问题是当我直接从shell运行二进制文件时程序运行良好，但当我使用GDB运行它时程序崩溃。这里有一些关于该程序的信息可能有用:它是一款已有20多年历史的数据库软件，最初是为Solaris编写的(我认为)但后来移植到Linux，它是setuid(但不是root，感谢上帝)。尝试打开文件进行写入时，程序在GDB中崩溃。使用GDB，我能够确定发生崩溃是因为以下系统调用失败:fd=open(path,O_WRONLY|O_CREAT|O_TRUNC,0644);澄清一下:path是一个锁文
我有正在运行的进程，但它的可执行文件已被删除。如果我尝试附加gdb，我会收到以下错误/home/vivek/binary/releases/20120328101511/bin/app.exe(deleted):Nosuchfileordirectory.如何将gdb附加到此进程？示例测试用例:源代码:#include#includeintmain(){for(;;){printf("Sleeping");sleep(1);}}编译它gccmain.cc-oa.outgccmain.cc-ob.out运行./a.out现在从不同的终端删除a.out。然后启动gdb附加pgrepa.ou
我正在尝试使用GNU汇编器学习ARM汇编器编程。我已经用QEmu设置了我的PC，并且有一个DebianARM-HFchroot环境。如果我汇编并链接我的测试程序:.text.global_start_start:movr0,#6bxlr与:astest.s-otest.oldtest.o-otest然后将文件载入gdb并在_start上设置断点:root@Latitude-E6420:/root#gdbtestGNUgdb(GDB)7.6.1(Debian7.6.1-1)Copyright(C)2013FreeSoftwareFoundation,Inc.LicenseGPLv3+:G
我在Linux下有一个小的C++项目。当我尝试使用gdb调试可执行文件时，出现以下错误:../../gdb/dwarf2read.c:16760:internal-error:follow_die_offset:Assertion'dwarf2_per_objfile->reading_partial_symbols'failed.AprobleminternaltoGDBhasbeendetected,furtherdebuggingmayproveunreliable.我已将项目大力简化为以下代码，但仍然出现相同的错误:B.h:#ifndefB_H_#defineB_H_#incl
我安装了libc6和libc6-dbg。(gdb)breakfreeifaddrs(gdb)runBreakpoint1,__freeifaddrs(ifa=0xa822e0)at../sysdeps/unix/sysv/linux/ifaddrs.c:840840../sysdeps/unix/sysv/linux/ifaddrs.c:Nosuchfileordirectory.(gdb)list835in../sysdeps/unix/sysv/linux/ifaddrs.c(gdb)disassembleDumpofassemblercodeforfunction__freeif
我的总体目标是从事后核心文件中找出特定进程消耗大量内存的原因。有没有我能以某种方式得到的摘要？显然valgrind是不可能的，因为我无法实时访问该过程。首先获得类似于/proc/"pid"/maps的输出，会有所帮助，但是maintenanceinfosections(如此处所述:GDB:Listingallmappedmemoryregionsforacrashedprocess)在gdb中没有显示堆内存消耗。infoprocmap是一个选项，因为我可以使用完全相同的代码访问机器，但据我所知，它是不正确的。我的进程使用了700MB-s，但是看到的map只占了大约10MB。而且我没
最近我正在做一些基于论文Bypassingnon-executable-stackduringexploitationusingreturn-to-libc的Return-to-libc攻击实验。使用我的Ubuntu11.10。在我的实验之前，我关闭了ALSR。根据论文，我可以在gdb中找到环境变量SHELL="/bin/bash"的地址(使用gdb调试我要攻击的程序):但是当我试图用它来Return-to-libc实验时，我发现这个地址是错误的。然后我写了一个简单的程序来获取环境变量地址:当我在终端中运行这个程序时，我得到了正确的地址:有了这个地址，我就可以进行攻击了。我还找到了相关
我正在尝试使用GDB在当前附加到的正在运行的进程中找到某个值(整数魔数(MagicNumber)(654321))。我找到了一个find[/sn]start_addr,+len,val1[,val2,...]命令，但它需要开始和结束地址，但我不知道我的进程内存从哪里开始以及结束的地方。这似乎是一个非常普遍的问题，但我记得一年前用谷歌搜索过它，现在我重复了一遍但没有成功，所以..我如何知道进程内存从哪里开始，从哪里结束？ 最佳答案 “所有内存”的概念在现代过程中很复杂。您真正拥有的是来自不同来源的许多映射。您可以枚举这些(确保不要尝试
我在gdb调试的时候执行ni命令遇到这样的错误:Warning:Cannotinsertbreakpoint0.Erroraccessingmemoryaddress0x3ac706a:Input/outputerror.0xf6fa4771insiglongjmp()from/lib/libc.so.6为了调查gdb遇到了什么问题，我对gdb进行了跟踪并得到了这样的输出:rt_sigprocmask(SIG_BLOCK,NULL,[RT_1],8)=0ptrace(PTRACE_PEEKTEXT,651,0xcc4fdf60,[0x1cc4fe470])=0ptrace(PTRACE
