小编Geo*_*rge的帖子

如何在Linux中获取C函数的手册页而不是shell命令手册？

例如,当我输入时,man bind我获取shell命令绑定的man而不是插件绑定C函数的man.

当我在分析核心转储时尝试打印以下行时,我收到此消息.

(gdb) p/x *($esi)
Cannot access memory at address 0xe6d3a030

我提到指出的地址%esi (0xe6d3a030)应该指向一些有效的分配数据.(当我自己运行这个程序并打破相同的指令时,这个打印有一些有意义的信息)

造成这种情况的可能原因是什么？我错过了核心转储中的一些信息吗？

如果是,我错过了什么信息？核心转储不应包含所有已分配内存的快照吗？

编辑:当我在加载coredump时使用gdb"维护信息部分"命令时,我得到的信息如下所示.我可以看到地址0xe6d3a030在范围内 0xe6d00000->0xe6dfb000 at 0x0f5aa000: load93 ALLOC LOAD HAS_CONTENTS这是不是意味着它被加载了？

(gdb) maintenance info sections 
Exec file:
    `/home/Administrator/Documents/coredump/myproc-debug-8.1.bin', file type elf32-i386.
    0x8048134->0x8048147 at 0x00000134: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
    0x8048148->0x8048168 at 0x00000148: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS
    0x8048168->0x804818c at 0x00000168: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
    0x804818c->0x80acd94 at 0x0000018c: .gnu.hash ALLOC LOAD READONLY DATA HAS_CONTENTS
    0x80acd94->0x8180d14 at 0x00064d94: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS …

我有一个分段错误后生成的核心转储.有没有办法在gdb(或其他方式)看到发生这种情况时的系统时间？

我无法使用核心转储文件的创建时间,因为它是在没有此元信息的情况下发送给我的.

在以下来自核心转储A2的回溯中:~A2被调用两次:

#0  0x086f5371 in B1::~B1 (this=0xe6d3a030, 
    __in_chrg=<value optimized out>)
    at /fullpath/b1.cpp:400
#1  0x086ffd43 in ~B2 (this=0xe6d3a030, 
    __in_chrg=<value optimized out>)
    at /fullpath/b2.h:21
#2  B2::~B2 (this=0xe6d3a030, 
    __in_chrg=<value optimized out>)
    at /fullpath/b2.h:21
#3  0x086ea516 in A1::~A1 (this=0xe3e93958, 
    __in_chrg=<value optimized out>)
    at /fullpath/a1.cpp:716
#4  0x0889b85d in A2::~A2 (this=0xe3e93958, 
    __in_chrg=<value optimized out>)
    at /fullpath/a2.cpp:216
#5  0x0889b893 in A2::~A2 (this=0xe3e93958, 
    __in_chrg=<value optimized out>)
    at /fullpath/a2.cpp:216
#6  0x0862c0f1 in E::Identify (this=0xe8083e20, t=PT_UNKNOWN)
    at /fullpath/e.cpp:713

A2来自A1,B2来自B1.只有B2有一个默认的析构函数,所有基类析构函数都是虚拟的.

代码看起来像这样:

e.cpp:

E::E(){
    //... some code ...
    myA1= new A2();
}

void …