gdb core 除錯
一般來說,段錯誤就是指訪問的記憶體超出了系統所給這個程式的記憶體空間，通常這個值是由gdtr來儲存的，他是一個48位的暫存器，其中的32位是儲存由它 指向的 gdt表，後13位儲存相應於gdt的下標，最後3位包括了程式是否在記憶體中以及程式的在cpu中的執行級別,指向的gdt是由以64位為一個單位的表， 在這張表中就儲存著程式執行的程式碼段以及資料段的起始地址以及與此相應的段限和頁面交換還有程式執行級別還有記憶體粒度等等的資訊。一旦一個程式發生了越界 訪問，cpu就會產生相應的異常保護，於是segmentation fault就出現了.
在程式設計中以下幾類做法容易導致段錯誤,基本是是錯誤地使用指標引起的
1)訪問系統資料區，尤其是往 系統保護的記憶體地址寫資料
最常見就是給一個指標以0地址
2)記憶體越界(陣列越界，變數型別不一致等) 訪問到不屬於你的記憶體區域
解決方法
我 們在用C/C++語言寫程式的時侯，記憶體管理的絕大部分工作都是需要我們來做的。實際上，記憶體管理是一個比較繁瑣的工作，無論你多高明，經驗多 豐富，難免會在此處犯些小錯誤，而通常這些錯誤又是那麼的淺顯而易於消除。但是手工“除蟲”（debug），往往是效率低下且讓人厭煩的，本文將就"段錯 誤"這個記憶體訪問越界的錯誤談談如何快速定位這些"段錯誤"的語句。
下面將就以下的一個存在段錯誤的程式介紹幾種除錯方法：
1 dummy_function (void)
2 {
3 unsigned char *ptr = 0x00;
4 *ptr = 0x00;
5 }
6
7 int main (void)
8 {
9 dummy_function ();
10
11 return 0;
12 }
作為一個熟練的C/C++程式設計師，以上程式碼的bug應該是很清楚的，因為它嘗試操作地址為0的記憶體區域，而這個記憶體區域通常是不可訪問的禁區，當然就會出錯了。我們嘗試編譯執行它:
段錯誤
果然不出所料，它出錯並退出了。
1.利用gdb逐步查詢段錯誤:
這種方法也是被大眾所熟知並廣泛採用的方法，首先我們需要一個帶有除錯資訊的可執行程式，所以我們加上“-g -rdynamic"的引數進行編譯，然後用gdb除錯執行這個新編譯的程式,具體步驟如下:
[email protected] test $ gcc -g -rdynamic d.c
[email protected] test $ gdb ./a.out
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /home/xiaosuo/test/a.out
Program received signal SIGSEGV, Segmentation fault.
0x08048524 in dummy_function () at d.c:4
4 *ptr = 0x00;
(gdb)
哦？！好像不用一步步除錯我們就找到了出錯位置d.c檔案的第4行，其實就是如此的簡單。
從這裡我們還發現程序是由於收到了SIGSEGV訊號而結束的。通過進一步的查閱文件(man 7 signal)，我們知道SIGSEGV預設handler的動作是列印”段錯誤"的出錯資訊，併產生Core檔案，由此我們又產生了方法二。
2.分析Core檔案：
Core檔案是什麼呢？
The default action of certain signals is to cause a process to terminate and produce a core dump file, a disk file containing an image of the process's memory at the time of termination. A list of the signals which cause a process to dump core can be found in signal(7).
以 上資料摘自man page(man 5 core)。不過奇怪了，我的系統上並沒有找到core檔案。後來，憶起為了漸少系統上的拉圾檔案的數量（本人有些潔癖，這也是我喜歡Gentoo的原因 之一），禁止了core檔案的生成，查看了以下果真如此，將系統的core檔案的大小限制在512K大小，再試:
0
[email protected] test $ ulimit -c 1000
[email protected] test $ ulimit -c
1000
[email protected] test $ ./a.out
段錯誤 (core dumped)
[email protected] test $ ls
a.out core d.c f.c g.c pango.c test_iconv.c test_regex.c
core檔案終於產生了，用gdb除錯一下看看吧:
[email protected]
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
warning: Can't read pathname for load map: 輸入/輸出錯誤.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x08048524 in dummy_function () at d.c:4
4 *ptr = 0x00;
哇，好歷害，還是一步就定位到了錯誤所在地，佩服一下Linux/Unix系統的此類設計。
接著考慮下去，以前用windows系統下的ie的時侯，有時開啟某些網頁，會出現“執行時錯誤”，這個時侯如果恰好你的機器上又裝有windows的編譯器的話，他會彈出來一個對話方塊，問你是否進行除錯，如果你選擇是，編譯器將被開啟，並進入除錯狀態，開始除錯。
Linux下如何做到這些呢？我的大腦飛速地旋轉著，有了，讓它在SIGSEGV的handler中呼叫gdb，於是第三個方法又誕生了:
3.段錯誤時啟動除錯:
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
void dump(int signo)
{
char buf[1024];
char cmd[1024];
FILE *fh;
snprintf(buf, sizeof(buf), "/proc/%d/cmdline", getpid());
if(!(fh = fopen(buf, "r")))
exit(0);
if(!fgets(buf, sizeof(buf), fh))
exit(0);
fclose(fh);
if(buf[strlen(buf) - 1] == '/n')
buf[strlen(buf) - 1] = '/0';
snprintf(cmd, sizeof(cmd), "gdb %s %d", buf, getpid());
system(cmd);
exit(0);
}
void
dummy_function (void)
{
unsigned char *ptr = 0x00;
*ptr = 0x00;
}
int
main (void)
{
signal(SIGSEGV, &dump);
dummy_function ();
return 0;
}
編譯執行效果如下:
[email protected] test $ gcc -g -rdynamic f.c
[email protected] test $ ./a.out
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
Attaching to program: /home/xiaosuo/test/a.out, process 9563
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7ee4b53 in waitpid () from /lib/libc.so.6
#2 0xb7e925c9 in strtold_l () from /lib/libc.so.6
#3 0x08048830 in dump (signo=11) at f.c:22
#4 <signal handler called>
#5 0x0804884c in dummy_function () at f.c:31
#6 0x08048886 in main () at f.c:38
怎麼樣？是不是依舊很酷？
以 上方法都是在系統上有gdb的前提下進行的，如果沒有呢？其實glibc為我們提供了此類能夠dump棧內容的函式簇，詳見 /usr/include/execinfo.h（這些函式都沒有提供man page，難怪我們找不到），另外你也可以通過gnu的手冊進行學習。
4.利用backtrace和objdump進行分析:
重寫的程式碼如下:
#include <execinfo.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
/* A dummy function to make the backtrace more interesting. */
void
dummy_function (void)
{
unsigned char *ptr = 0x00;
*ptr = 0x00;
}
void dump(int signo)
{
void *array[10];
size_t size;
char **strings;
size_t i;
size = backtrace (array, 10);
strings = backtrace_symbols (array, size);
printf ("Obtained %zd stack frames./n", size);
for (i = 0; i < size; i++)
printf ("%s/n", strings[i]);
free (strings);
exit(0);
}
int
main (void)
{
signal(SIGSEGV, &dump);
dummy_function ();
return 0;
}
編譯執行結果如下：
[email protected] test $ gcc -g -rdynamic g.c
[email protected] test $ ./a.out
Obtained 5 stack frames.
./a.out(dump+0x19) [0x80486c2]
[0xffffe420]
./a.out(main+0x35) [0x804876f]
/lib/libc.so.6(__libc_start_main+0xe6) [0xb7e02866]
./a.out [0x8048601]
這次你可能有些失望,似乎沒能給出足夠的資訊來標示錯誤,不急,先看看能分析出來什麼吧,用objdump反彙編程式,找到地址0x804876f對應的程式碼位置:
[email protected] test $ objdump -d a.out
8048765: e8 02 fe ff ff call 804856c <[email protected]>
804876a: e8 25 ff ff ff call 8048694 <dummy_function>
804876f: b8 00 00 00 00 mov $0x0,%eax
8048774: c9 leave
我們還是找到了在哪個函式(dummy_function)中出錯的,資訊已然不是很完整,不過有總比沒有好的啊!
相關推薦
gdb core 除錯
簡而言之,產生段錯誤就是訪問了錯誤的記憶體段，一般是你沒有許可權，或者根本就不存在對應的實體記憶體,尤其常見的是訪問0地址. 一般來說,段錯誤就是指訪問的記憶體超出了系統所給這個程式的記憶體空間，通常這個值是由gdtr來儲存的，他是一個48位的暫存器，其中的32位是儲存由它 指向的 gdt表，後13位儲存相應
GDB遠端除錯程式 & 生成core檔案便於除錯
# GDB遠端除錯程式 **該檔案是用於遠端除錯gdb，資料夾中的gdbserver和arm-linux-gdb的版本已經保持一致均為6.4** 1. target：`./gdbserver6.4 192.168.100.101:8888 ./test_scale` 2. hos
GDB遠端除錯程式 & 生成core檔案便於除錯
# GDB遠端除錯程式 **該檔案是用於遠端除錯gdb，資料夾中的gdbserver和arm-linux-gdb的版本已經保持一致均為6.4** 1. target：`./gdbserver6.4 192.168.100.101:8888 ./test_scale` 2
gdb core檔案除錯
段錯誤是在程式設計中造成程式異常中斷退出的主要原因之一，並且不易覺察，也許很快發現，也有可能程式執行很長一段時間才發生段錯誤。正因為段錯誤發生的不確定性，所以除錯段錯誤是一個很耗時的過程
GDB core命令的使用調試段錯誤
har tdi round image 錯誤 ffffff fff 命令 技術分享 #include <stdio.h> void func(){ int *p = NULL; printf("*p:%d\n", *p);//斷錯誤 } int main(
gdb動態除錯得到目標flag
首先IDA載入很容易可以看出get_flag函式是關鍵 程式只有一個簡單的比較 0x01：gdb sysmagic載入目標 r是執行 c是繼續 b是下斷點 0x02：disas 對函式進行反彙編 對比IDA我們
gdb watch 除錯時，無法watch
伺服器實際執行時， 某個物件的某個變數不知道啥時候被改掉了。 用valgrind查了 ，沒有記憶體越界， 那就是邏輯上有問題。 這種情況 gdb 的 watch功能就非常好用。 它能檢測記憶體中的值被改了，就會自動斷點。
GDB常用除錯命令（二）
GDB訊號處理 在GDB中使用handle命令定義一個訊號處理。訊號可以以SIG開頭或不以 SIG開頭，可以用定義一個要處理訊號的範圍（如：SIGIO-SIGKILL，表示處理從SIGIO訊號到SIGKILL的訊號，其中包括SIGIO， SIGIOT，S
GDB程式除錯工具
使用gcc/g++編譯程式時加-g選項以方便除錯。 設定系統允許產生core檔案: $ulimit -c unlimited 除錯由test程式產生的core檔案: $gdb ./test core 設定輸出資訊時的分頁功能 set pagination on # 或者 set heigh
linux下 gdb+coredump 除錯偶發crash的程式
1. 開啟 core dump 檢視是否開啟 ulimit -c 如果輸出0, 說明沒有開啟。 方法一：使用命令 ulimit -c unlimited 可以開啟，但是隻對當前終端有效， 方法二： 配置 /etc/profile 檔案 su
在MacOS上使用gdb(cgdb)除錯Golang程式
如果你在MacOS上使用GDB工具載入Golang程式時無法載入，這篇文章可以解決。本文不具體介紹除錯的方法，網上的文章太多了就不贅述了。 cgdb使用的是gdb的核心，方法和原理試用本文。 問題分析 最近接觸Go語言，看了慕課網的這篇文章，裡面介紹的Go函式，有一種JavaScript的風格，把我弄迷糊
dotnet core除錯docker下生成的dump檔案
最近公司預生產環境的docker容器經常出現記憶體暴漲現象，有時會突然吃掉幾個G,觸發監控預警，造成容器重啟。 分析了各種可能原因，修復了可能發生的記憶體洩露，經測試本地正常，但是發到預生產還是會有記憶體暴漲現象，反而更改GC模式後記憶體使用保持較低水平，百思不得其解，所以想到使用除錯dump檔案方式來分析
fgets()與gets()函式的區別，並用gdb工具除錯驗證
南昌大學工程實驗報告 學生姓名：秦琦琛 學 號： 8000116350 專業班級：軟工1611班 實驗型別：■ 驗證 □ 綜合 □ 設計 □ 創新 實驗日期： 2018、10、8 實驗成績： 一、實驗目的 熟悉linux
Linux下gdb的除錯
一、Linux下的gdb除錯 要使用gdb除錯，必須在原始碼生成二進位制程式時，加上-g 選項 例如：gcc -o main main.c -g 二、如何除錯 首先，先把程式碼
gdb 製作除錯 NS2.34
1、製作debug版本 製作tcl,tk,otcl,tclcl的debug版本的靜態連結庫檔案，並將其複製到ns-allinone-2.34/lib/目錄下。tcl,tk,otcl,tclcl之間是有相互依賴關係的，編譯的時候應當注意按 tcl > tk > otcl > tc
Linux核心之GDB基本除錯方法
Oops[#1]:Cpu 0$ 0 : 00000000 10008d00 00000000 ffffffea$ 4 : fffffdfd 10008d01 00000001 00000000$ 8 : 00000000 7fed2e40 00001cb2 00000b3b$12 : 0003
gdb-pada除錯例項
先編寫個簡單的hello的程式 hello.c (ps:有沒有標頭檔案行不行，試試不就知道了) 1 int main(){ 2 printf("hello!\n"); 3 int m,n; 4 int array[5] = {1,2,3,4,5}; 5
使用Qemu+gdb來除錯核心
昨天聽別人講使用Qemu和gdb來實現原始碼級核心除錯，今天試了一下，果然非常方便，現簡單的記錄一下。 Qemu是一個開源的虛擬機器軟體，能夠提供全系統的模擬，可以執行在多個平臺上，並模擬多個別的平臺。Qemu虛擬機器是採用動態翻譯來實現CPU的模擬的，對硬體的依賴程度低，
GDB attach 除錯
手賤寫個bug，索性看看gdb。 首先寫個簡單的多執行緒小程式用於測試： #include <pthread.h> #include <stdio.h> #include <unistd.h>
Linux核心分析之三——使用gdb跟蹤除錯核心從start_kernel到init程序啟動
作者：姚開健 原創作品轉載請註明出處 《Linux核心分析》MOOC課程http://mooc.study.163.com/course/USTC-1000029000 Linux核心（本文以Linux-3.18.6為例）的啟動在原始碼init資料夾裡的main.c