小编bar*_*ryd的帖子

为什么 gdb 抱怨我的核心文件太小,然后无法生成有意义的堆栈跟踪?

我有一个由段错误生成的核心文件。当我尝试将其加载到 gdb 中时,如何加载它或者是否使用正确的可执行文件似乎并不重要 - 我总是从 gdb 收到有关核心文件被截断的警告:

$ gdb -q /u1/dbg/bin/exdoc_usermaint_pdf_compact /tmp/barry/core.exdoc_usermaint.11
Reading symbols from /u1/dbg/bin/exdoc_usermaint_pdf_compact...done.
BFD: Warning: /tmp/barry/core.exdoc_usermaint.11 is truncated: expected core file size >= 43548672, found: 31399936.

warning: core file may not match specified executable file.
Cannot access memory at address 0x7f0ebc833668
(gdb) q
Run Code Online (Sandbox Code Playgroud)

我担心这个错误:“BFD:警告:/tmp/barry/core.exdoc_usermaint.11 被截断:预期核心文件大小 >= 43548672,发现:31399936。”

为什么gdb认为核心文件被截断了?gdb是对的吗?gdb 从哪里获得核心文件的预期大小,我可以仔细检查它吗?

背景:

我正在尝试改进对生产系统中的段错误的诊断。我的计划是从生产中剥离的可执行文件中获取核心文件,并将它们与我们开发系统上可执行文件的调试版本一起使用,以快速诊断段错误。在这个问题的早期版本中,我提供了与相似但不同的系统相关的许多细节,但后来我被授予了我们生产系统的帐户,并确定大多数细节对问题并不重要。

gdb版本:

$ gdb
GNU gdb (GDB) Fedora (7.0.1-50.fc12)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is …
Run Code Online (Sandbox Code Playgroud)

c gdb coredump fedora

5
推荐指数
1
解决办法
7620
查看次数

为什么在使用单独的调试符号文件时gdb“无法计算CFA”?

我正在尝试通过运行剥离的可执行文件生成的核心转储,使用剥离的可执行文件和单独的调试符号文件调用gdb。

但是,当我使用单独的调试符号文件时,gdb无法为我提供有关局部变量的信息。

这是完整显示我如何生成3个ELF文件和核心文件,然后在gdb中运行它们3次的日志。

  1. 首先,我只使用剥离后的可执行文件运行gdb,当然看不到任何文件名或行号,也无法检查变量。

  2. 然后,我使用剥离的可执行文件运行gdb,并从原始的未剥离的可执行文件中获取调试符号。这工作得很好,但是确实给出了有关内核和可执行文件可能不匹配的令人不安且显然毫无根据的警告。

  3. 最后,我使用剥离的可执行文件和单独的调试文件运行gdb。它仍然提供文件名和行号,但是我无法检查局部变量,并且收到“无法为此帧计算CFA”错误。

这是日志:

2016-09-16 16:01:45 barry@somehost ~/proj/segfault/segfault
$ cat segfault.c
#include <stdio.h>
int main(int argc, char **argv) {
    char *badpointer = (char *)0x2398723;
    printf("badpointer: %s\n", badpointer);
    return 0;
}

2016-09-16 16:03:31 barry@somehost ~/proj/segfault/segfault
$ gcc -g -o segfault segfault.c

2016-09-16 16:03:37 barry@somehost ~/proj/segfault/segfault
$ objcopy --strip-debug segfault segfault.stripped

2016-09-16 16:03:40 barry@somehost ~/proj/segfault/segfault
$ objcopy --only-keep-debug segfault segfault.debug

2016-09-16 16:03:43 barry@somehost ~/proj/segfault/segfault
$ ./segfault.stripped
Segmentation fault (core dumped)

2016-09-16 16:03:48 barry@somehost ~/proj/segfault/segfault
$ ll /tmp/core.segfault.stripp.11
-rw------- 1 …
Run Code Online (Sandbox Code Playgroud)

c debugging gcc gdb

3
推荐指数
1
解决办法
4018
查看次数

为什么我的核心转储缺少 NT_FILE 注释?

我在 Fedora 系统上设置了“ulimit -c unlimited”,以便段错误生成核心转储文件。这是有效的。

我在这些 URL 上看到过 NT_FILE 注释:

ELF核心文件格式

ELF 核心文件剖析

但我的核心文件只包含这些注释:

$ readelf --notes core.simple.11

Notes at offset 0x000003f8 with length 0x00000558:
  Owner     Data size   Description
  CORE      0x00000150  NT_PRSTATUS (prstatus structure)
  CORE      0x00000088  NT_PRPSINFO (prpsinfo structure)
  CORE      0x00000130  NT_AUXV (auxiliary vector)
  CORE      0x00000200  NT_FPREGSET (floating point registers)
Run Code Online (Sandbox Code Playgroud)

为什么没有NT_FILE注释? 如何找出核心文件可能基于的各种目标文件,更重要的是,如何找出这些文件映射到核心映像的虚拟地址?

如果没有 NT_FILE 注释中的地址映射信息,我不知道如何在目标文件的 DWARF 调试信息中执行代码地址查找。

核心文件中的程序头:

$ readelf --segments core.simple.11

Elf file type is CORE (Core file)
Entry point 0x0
There are 17 program headers, starting at offset …
Run Code Online (Sandbox Code Playgroud)

gdb coredump fedora dwarf

3
推荐指数
1
解决办法
1366
查看次数

标签 统计

gdb ×3

c ×2

coredump ×2

fedora ×2

debugging ×1

dwarf ×1

gcc ×1