反編譯core文件
❶ linux 怎麼分析core文件
從接觸unix開始就一直聽到和遇到core mp，特別是剛學著使用C語言在AIX下編寫程序的時候，core mp更是時不時就會不請自來。記得當時剛寫應用的時候，提交程序時最怕的就是在運行過程時遇到core mp，對於銀行核心系統，特別是使用靜態應用進程，如果一個相對頻繁一點的交易導致core mp，那麼毫無疑問，除了趕緊定位錯誤改程序外，重啟進程甚至無法爭取到多少緩沖的時間來進行代碼的更正和測試。而且往往導致core mp的，就是程序中一個小小的未注意到或者未測試到的一個疏忽。
雖然常常遇到core mp，不過很長時間內，都是出於知道這個名字，知道它導致的後果，知道一部分導致它出現的原因，其他的就都不甚了了了。說起來，就是自己太懶了，懶得看書......少壯不努力啊。看過一則統計，說60歲以上的老人，超過70%都後悔少壯不努力，不知統計的數據能否反映整個社會的情況。不過總的來說，這句古話還是有些道理的。大家不要學我。哈哈
core mp，翻譯過來講，就是核心轉儲。大致上就是指，如果由於應用錯誤，如浮點異常、指令異常等，操作系統將會轉入內核的異常處理，向對應的進程發送特定的信號（SIGNAL），如果進程中沒有對這些信號進行處理，就會轉入默認的處理，core mp就是其中的一種。如果進程core mp，系統將會終止該進程，同時系統會產生core文件，以供調試使用。這個core文件其實就是內存的映像，即進程執行的時候內存的內容，也就是所謂的core mp。平常大家說某某進程core mp了，其實主要的意思就是說：某某進程因為錯誤而被系統自動終止了。
AIX上提供了dbx工具可以對core mp進行調試，協助定位引起core mp的代碼。最普通的語法是：
dbx 應用名 core文件， 然後使用where命令來顯示調試信息
一般來講，根據工作中遇到的情況，dbx還是能夠比較輕松的根據提示的內容來定位代碼的。不過也有一些特殊情況時，dbx顯示的調試信息過於模糊或者不直觀，這個時候就只能根據經驗來逐步定位了。有時定位起來會耗用相當長的時間。遇到這種情況時，使用日誌文件，通過在代碼中穿插多個寫log的語句，也可以協助發現。因為進程core mp時，日誌當然也中斷了，根據日誌在哪個代碼行之後或之前中止了，可以有效縮小尋找的范圍。甚至，在有些情況下，使用日誌定位是唯一簡便的方法了。
❷ 如何根據core文件中錯誤地址定位程序
The problem that no `core' file is created on a segmentation fault; Locate errors in the source with GDB and `core' files
Linux 程序在遇到段錯誤(常見的是由非法訪問內存引起)的時候會產生 core 文件，如果這個程序包含調試信息(編譯的時候加 -g 選項)，那麼使用 gdb 讀取這個 core 文件可以快速定位出錯的源代碼。原來在某軟體公司實習的時候(用 RedHat Enterprise Linux)覺得這樣非常方便查錯，但我自己用的 Debian GNU/Linux 卻默認不生成這個文件。
檢查以後發現原因是 core 文件最大尺寸(用 ulimit -c 查看)是 0，把它設置成非 0 值就可以了，如:
ulimit -c 2048(設置 core 文件最大尺寸為 2048 blocks，1block=512bytes，因此這里設置的其實是 1MiB)
ulimit -c unlimited(不限 core 文件尺寸)
附:用 gdb 根據 core mp 文件定位錯誤的辦法。
用這個程序作一個測試:
int foo (int *p)
{
return *p;
}
main()
{
foo (0);
}
derek@dli: /tmp $ gcc -g a.c
derek@dli: /tmp $ ./a.out
段錯誤 (core mped)
derek@dli: /tmp $ gdb ./a.out -c core
(這里略去約十行其他信息)
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x0804834a in foo (p=0x0) at a.c:3
3 return *p;
如果再輸入一條命令 bt，就可以看得清清楚楚錯誤是在什麼時機產生的:
(gdb) bt
#0 0x0804834a in foo (p=0x0) at a.c:3
#1 0x0804836b in main () at a.c:8
不能有比這更清楚的錯誤信息了!如果是在 Windows 下，就老老實實 Trace and Step 吧。
❸ 反編譯.odex是 出現了下面的錯誤，意思是 缺少core.odex文件 但我已經把framework下的所有文件復制到
要先把core.apk和core.odex合並之後再進行反編譯，不然就會提示這個。
❹ 根目錄下生成很多core.文件是什麼原因
在 UNIX/Linux 系統中，core 文件往往是由於用戶編寫的程序有問題，但是又不是在編譯、連接程序時就可以輕易發現的錯誤，但是一到運行程序時才會產生：core mped 信息。一般來說，core 文件佔用的空間比較大，也沒有什麼太多的用處，因此可以刪除掉它。
❺ core是什麼文件夾可以刪除嗎
咨詢記錄 · 回答於2022-01-01
❻ 如何分析core
什麼是Core Dump?
Core的意思是內存, Dump的意思是扔出來, 堆出來.
開發和使用Unix程序時, 有時程序莫名其妙的down了, 卻沒有任何的提示(有時候會提示core mped). 這時候可以查看一下有沒有形如core.進程號的文件生成, 這個文件便是操作系統把程序down掉時的內存內容扔出來生成的, 它可以做為調試程序的參考.
core mp又叫核心轉儲, 當程序運行過程中發生異常, 程序異常退出時, 由操作系統把程序當前的內存狀況存儲在一個core文件中, 叫core mp.
如何使用core文件?
gdb -c core文件路徑 [應用程序的路徑]
進去後輸入where回車, 就可以顯示程序在哪一行當掉的, 在哪個函數中.
為什麼沒有core文件生成呢?
有時候程序down了, 但是core文件卻沒有生成. core文件的生成跟你當前系統的環境設置有關系, 可以用下面的語句設置一下, 然後再運行程序便成生成core文件.
ulimit -c unlimited
core文件生成的位置一般於運行程序的路徑相同, 文件名一般為core.進程號
可以執行limit命令具體的取值，如下：
<75 sersrv1 [pisac10] :/home/pisac10>limit
cputime unlimited
filesize unlimited
datasize unlimited
stacksize unlimited
corempsize 4194303 kbytes
memoryuse unlimited
vmemoryuse unlimited
descriptors 1024
memorylocked unlimited
maxproc 69632
如果發現某些選項達不到要求，可以將這些放大
用gdb查看core文件:
下面我們可以在發生運行時信號引起的錯誤時發生core mp了.
發生core mp之後, 用gdb進行查看core文件的內容, 以定位文件中引發core mp的行.
gdb [exec file] [core file]
如:
gdb ./test test.core
在進入gdb後, 用bt命令查看backtrace以檢查發生程序運行到哪裡, 來定位core mp的文件->行.
如何知道一個core文件是哪個進程的：
使用file core文件命令就可以了，如下：
<63 sersrv1 [pisac10] :/home/pisac10>file core.3118
core.3118: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, SVR4-style, from 'csser'
SUSE Linux操作系統可以使用kill -7 進程號 命令強制殺掉進程並且產生core文件
thread apply all where
❼ 怎樣用GDB調試core文件
一般這種情況都是因為數組越界訪問，空指針或是野指針讀寫造成的。程序小的話還比較好辦，對著源代碼仔細檢查就能解決。但是對於代碼量較大的程序，里邊包含N多函數調用，N多數組指針訪問，這時想定位問題就不是很容易了（此時牛人依然可以通過在適當位置打printf加二分查找的方式迅速定位:P）。懶人的話還是直接GDB搞起吧。 神馬是Core Dump文件偶爾就能聽見某程序員同學抱怨「擦，又出Core了！」。簡單來說，core mp說的是操作系統執行的一個動作，當某個進程因為一些原因意外終止（crash）的時候，操作系統會將這個進程當時的內存信息轉儲（mp）到磁碟上1。產生的文件就是core文件了，一般會以core.xxx形式命名。 如何產生Core Dump 發生doremp一般都是在進程收到某個信號的時候，Linux上現在大概有60多個信號，可以使用 kill -l 命令全部列出來。sagi@sagi-laptop:~$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX針對特定的信號，應用程序可以寫對應的信號處理函數。如果不指定，則採取默認的處理方式, 默認處理是coremp的信號如下：3)SIGQUIT 4)SIGILL 6)SIGABRT 8)SIGFPE 11)SIGSEGV 7)SIGBUS 31)SIGSYS 5)SIGTRAP 24)SIGXCPU 25)SIGXFSZ 29)SIGIOT 我們看到SIGSEGV在其中，一般數組越界或是訪問空指針都會產生這個信號。另外雖然默認是這樣的，但是你也可以寫自己的信號處理函數改變默認行為，更多信號相關可以看參考鏈接33。 上述內容只是產生coremp的必要條件，而非充分條件。要產生core文件還依賴於程序運行的shell，可以通過ulimit -a命令查看，輸出內容大致如下：sagi@sagi-laptop:~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheling priority (-e) 20 file size (blocks, -f) unlimited pending signals (-i) 16382 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited 看到第一行了吧，core file size，這個值用來限制產生的core文件大小，超過這個值就不會保存了。我這里輸出是0，也就是不會保存core文件，即使產生了，也保存不下來==! 要改變這個設置，可以使用ulimit -c unlimited。 OK, 現在萬事具備，只缺一個能產生Core的程序了，介個對C程序員來說太容易了。#include ; #include ; int crash() { char *xxx = "crash!!"; xxx[1] = 'D'; // 寫只讀存儲區! return 2; } int foo() { return crash(); } int main() { return foo(); } 上手調試 上邊的程序編譯的時候有一點需要注意，需要帶上參數-g, 這樣生成的可執行程序中會帶上足夠的調試信息。編譯運行之後你就應該能看見期待已久的「Segment Fault(core mped)」或是「段錯誤 (核心已轉儲)」之類的字眼了。看看當前目錄下是不是有個core或是core.xxx的文件。祭出linux下經典的調試器GDB，首先帶著core文件載入程序：gdb exefile core，這里需要注意的這個core文件必須是exefile產生的，否則符號表會對不上。載入之後大概是這個樣子的：sagi@sagi-laptop:~$ gdb coremp core Core was generated by ./coremp'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in crash () at coremp.c:8 8 xxx[1] = 'D'; (gdb)我們看到已經能直接定位到出core的地方了，在第8行寫了一個只讀的內存區域導致觸發Segment Fault信號。在載入core的時候有個小技巧，如果你事先不知道這個core文件是由哪個程序產生的，你可以先隨便找個代替一下，比如/usr/bin/w就是不錯的選擇。比如我們採用這種方法載入上邊產生的core，gdb會有類似的輸出：sagi@sagi-laptop:~$ gdb /usr/bin/w core Core was generated by ./coremp'. Program terminated with signal 11, Segmentation fault. #0 0x080483a7 in ? () (gdb)可以看到GDB已經提示你了，這個core是由哪個程序產生的。 GDB 常用操作 上邊的程序比較簡單，不需要另外的操作就能直接找到問題所在。現實卻不是這樣的，常常需要進行單步跟蹤，設置斷點之類的操作才能順利定位問題。下邊列出了GDB一些常用的操作。 啟動程序：run
設置斷點：b 行號|函數名
刪除斷點：delete 斷點編號
禁用斷點：disable 斷點編號
啟用斷點：enable 斷點編號
單步跟蹤：next 也可以簡寫 n
單步跟蹤：step 也可以簡寫 s
列印變數：print 變數名字
設置變數：set var=value
查看變數類型：ptype var
順序執行到結束：cont
順序執行到某一行： util lineno列印堆棧信息：bt
❽ 怎麼打開core文件
core文件是由應用程序收到系統信號後崩潰產生的，該文件中記錄了程序崩潰的原因(例如收到那種信號)，調用堆棧和崩潰時的內存及變數值等等的信息。 打開core文件與編譯時使用的編譯器有關，但絕大多數linux程序是使用gcc編譯器編譯的，因此可使用對應gdb調試器打開，命令格式如下： $ gdb 應用程序文件名 core文件名 舉例： $ gdb /usr/bin/gedit ~/core ------ 查看由gedit崩潰產生的core文件 (gdb) bt ------ 或者backtrace, 查看程序運行到當前位置之前所有的堆棧幀情況) (gdb) quit ------ 退出 如果不知道core文件由哪個文件產生的，可使用file命令顯示 $ file cor
❾ 什麼是core文件，怎麼產生core文件
但這不像編譯錯誤一樣會提示到文件-行, 而是沒有任何信息, 使得我們的調試變得困難起來. 2. gdb:有一種辦法是, 我們用gdb的step, 一步一步尋找. 這放在短小的代碼中是可行的, 但要讓你step一個上萬行的代碼, 我想你會從此厭惡程序員這個名字, 而把他叫做調試員. 我們還有更好的辦法, 這就是core file. 3. ulimit:如果想讓系統在信號中斷造成的錯誤時產生core文件, 我們需要在shell中按如下設置: #設置core大小為無限 ulimit -c unlimited #設置文件大小為無限 ulimit unlimited 這些需要有root許可權, 在ubuntu下每次重新打開中斷都需要重新輸入上面的第一條命令, 來設置core大小為無限. 4. 用gdb查看core文件: