1. 程式人生 > >使用GDB分析core dump檔案

使用GDB分析core dump檔案


到此配置工作完成,下面對core檔案進行分析。
比如我們執行的程式碼出現段錯誤,如下:
[[email protected] mywork]# ./testGdb
Segmentation fault (core dumped)
[[email protected] mywork]#
[[email protected] mywork]# gdb testGdb core-testGdb

GNU gdb (GDB) Fedora (7.0-3.fc12)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/mywork/testGdb...done.

warning: .dynamic section for "/lib/libc.so.6" is not at the expected address

warning: difference appears to be caused by prelink, adjusting expectations
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./testGdb'.
Program terminated with signal 11, Segmentation fault.//顯示出了程式崩潰的原因如下
#0  0x0804839a in copy (t=0x0) at testGdb.c:5
5        *t = 10;
Missing separate debuginfos, use: debuginfo-install glibc-2.11-2.i686
(gdb) bt //顯示函式呼叫堆疊,顯然是main函式呼叫copy函式
#0  0x0804839a in copy (t=0x0) at testGdb.c:5
#1  0x080483b0 in main () at testGdb.c:11
(gdb) f 1 //列印棧號為1的堆疊,顯示main函式是怎麼呼叫copy函式,f的全名為frame
#1  0x080483b0 in main () at testGdb.c:11
11        copy(s);
(gdb) p s  //列印變數的值
$1 = 0x0

相關推薦

使用GDB分析core dump檔案

到此配置工作完成,下面對core檔案進行分析。 比如我們執行的程式碼出現段錯誤,如下: [[email protected] mywork]# ./testGdb Segmentation fault (core dumped) [[email protected] mywork]#

linux core dump 檔案 gdb分析【轉】

core dump又叫核心轉儲, 當程式執行過程中發生異常, 程式異常退出時, 由作業系統把程式當前的記憶體狀況儲存在一個core檔案中, 叫core dump. (linux中如果記憶體越界會收到SIGSEGV訊號,然後就會core dump) 在程式執行的過程中,有

gdb分析core檔案及常見gdb命令操作示例

1.概述 在實際的軟體開發專案中,程式出現問題是在所難免的。遙想本人蔘加工作之後首次遇到程式的情景,至今還歷歷在目。之前的經驗告訴我,我們越是驚慌失措,問題就越是解決不了。我們要先讓自己平靜下來,然後再尋找解決程式問題的辦法。 在Linux下做開發的朋友,想

[skill][debug][gdb] 使用core dump 進行GDB

bsp mit kill nbsp ase pgrep -- org 發生 core dump 掃盲:https://wiki.archlinux.org/index.php/Core_dump 1. 人為制作 core dump   1.1 實時在線生成cor

如何查詢和修改Linux作業系統生成core dump檔案的預設路徑?

最近遇到一個問題,SUSE Linux系統中的某個應用程式異常而最終引發了系統core dump,但遺憾的時在系統重啟後並沒有找到core檔案,影響了我們對問題的分析定位。 經過分析發現系統預設的core檔案生成路徑是/var/logs,但/var/logs目錄並非系統自帶的,系統初始安裝預設自帶的

使用gdbcore dump如何快速定位到段錯誤

這篇文章主要介紹的就是在產生段錯誤時如何快速定位到錯誤的位置?  一.一個簡單的關於段錯誤的例項 #include<stdio.h> #include<signal.h&

gdb除錯core dump入門實踐(順便複習一下之前介紹過的addr2line命令除錯)

        除錯技能是軟體開發的必備技能, 不會除錯, 就抓不到bug, 就很痛苦。 本文我們來一起聊聊gdb除錯core          Part 1:         在前面的博文中, 我們聊過重要的addr2line除錯, 現在再來一起看看, 就當是複習吧。

分析java dump檔案

注意,請不要被我誤導,我沒有看其他資料,這是我自己分析的,有些可能是不對的 "DestroyJavaVM" prio=6 tid=0x00316800 nid=0x448 waiting on condition [0x00000000 ..0x00a0fd4c]   

例項講解:使用IBM heapAnalyzer分析heap dump檔案步驟

需求動機:解決 OOM( Object Out of Memory)問題以及系統調優 1.如何產生 java heap dump 當 JVM中物件過多, java堆( java heap)耗盡時,就會產生 java heap dump檔案。另外,可以使用工具或命令

在Linux上生成Core Dump檔案的配置

Linux生成core dump的做法 一、 核心必須開啟選項 CONFIG_ELF_CORE; 二、配置每個程序的RLIMIT_CORE資源為RLIM_INFINITY。方法有二: 1. 在busybox的init/init.c原始檔定義了巨集CORE_ENABLE_

使用gdbcore dump迅速定位段錯誤

一、什麼是core dump     core:記憶體、核心的意思;     dump:丟擲,扔出;     core dump:前提:當某程式崩潰的一瞬間,核心會丟擲當時該程式程序的記憶體詳細情況,儲存在一個名叫core.xxx(xxx為一個數字,比如core.6

linux core dump檔案生成和除錯

1.core dump檔案生成 project(coredumptest) cmake_minimum_required(VERSION 2.8) add_compile_options(-std=c++11 -pthread -g -ggdb -O

使用Crash工具分析 Linux dump檔案

前言 Linux 核心(以下簡稱核心)是一個不與特定程序相關的功能集合,核心的程式碼很難輕易的在偵錯程式中執行和跟蹤。開發者認為,核心如果發生了錯誤,就不應該繼續運 行。因此核心發生錯誤時,它的行為通常被設定為系統崩潰,機器重啟。基於動態儲存器的電氣特性,機器重啟後,

linux下生成core dump檔案方法及設定

ulimit -c 1024鍵入 ulimit -c如果顯示 1024 那麼說明 coredump 已經被開啟。1024 限制產生的 core 檔案的大小不能超過 1024kb,可以使用引數unlimited,取消該限制ulimit -c unlimited

windows下生成core dump檔案

http://blog.csdn.net/xiarendeniao/article/details/7306282 下面是從pandion裡面摘取的兩個檔案 MiniDumper.h #ifndef MINIDUMPER_H

使用 Crash 工具分析 Linux dump 檔案

前言 Linux 核心(以下簡稱核心)是一個不與特定程序相關的功能集合,核心的程式碼很難輕易的在偵錯程式中執行和跟蹤。開發者認為,核心如果發生了錯誤,就不應該繼續執行。因此核心發生錯誤時,它的行為通常被設定為系統崩潰,機器重啟。基於動態儲存器的電氣特性,機器重啟後,上次錯誤發生時的現場會遭到破壞,這使得

gdb除錯core檔案快速定位core dump位置

core dump又叫核心轉儲, 當程式執行過程中發生異常, 程式異常退出時, 由操作系統把程式當前的記憶體狀況儲存在一個core檔案中, 叫core dump. (linux中如果記憶體越界會收到SIGSEGV訊號,然後就會core dump) 在程式執行的過程中,有的時

【Z】段錯誤Segment Fault定位,即core dump文件與gdb定位

rect fun 發生 toolbar ulimit top wid title 沒有 使用C++開發系統有時會出現段錯誤,即Segment Fault。此類錯誤程序直接崩潰,通常沒有任何有用信息輸出,很難定位bug,因而無從解決問題。今天我們介紹core dump文件,

【取證分析】用linux命令xxd來獲取dump檔案資訊獲得flag

題目連結:https://blog.csdn.net/xiangshangbashaonian/article/details/82747394 拿到一道CTF題目  notepad++開啟如下所示 [email protected]:~/Desktop$ fi

使用GDB除錯PHP Core Dump

注意到PHP崩潰了 沒有絕對的方法可以知道PHP崩潰,但可能有跡象。通常,如果您訪問始終應該生成輸出的頁面(例如,具有前導HTML塊),並且突然從瀏覽器中獲取“文件不包含資料”,則可能意味著PHP在執行時崩潰了某處。指令碼。告訴PHP崩潰的另一種方法是檢視Apache錯誤日誌,並查詢SEGV(A