1. linux部署下的tomcat5.5的bin目錄下有個core文件達到好幾G，能刪除嗎這文件是幹嘛的
可以刪除，core文件是有錯誤時給出的文件。之前我用tomcat發現只要啟動失敗就會出現這個core，而且每個都很大。刪了不影響。
2. 如何察看core文件的內容
一般步驟1.filecore文件，可以顯示出core文件是哪個進程產生的2.使用gdb或者dbx載入core文件，gdb進程名core文件3.where,顯示堆棧信息，顯示出coremp的地方例如有個程序叫ABC，產生了一個叫core的core文件，那麼輸入filecore,會顯示這個core文件是由ABC產生的，然後輸入gdbABCcore裝截core文件，然後輸入where顯示堆棧信息
3. linux core 文件 怎麼分析
Core，又稱之為Core Dump文件，是/Linux操作系統的一種機制，對於線上服務而言，Core令人聞之色變，因為出Core的過程意味著服務暫時不能正常響應，需要恢復，並且隨著吐Core進程的內存空間越大，此過程可能持續很長一段時間（例如當進程佔用60G+以上內存時，完整Core文件需要15分鍾才能完全寫到磁碟上），這期間產生的流量損失，不可估量。
凡事皆有兩面性，OS在出Core的同時，雖然會終止掉當前進程，但是也會保留下第一手的現場數據，OS彷彿是一架被按下快門的相機，而照片就是產出的Core文件。裡面含有當進程被終止時內存、CPU寄存器等信息，可以供後續開發人員進行調試。
關於Core產生的原因很多，比如過去一些Unix的版本不支持現代Linux上這種GDB直接附著到進程上進行調試的機制，需要先向進程發送終止信號，然後用工具閱讀core文件。在Linux上，我們就可以使用kill向一個指定的進程發送信號或者使用gcore命令來使其主動出Core並退出。如果從淺層次的原因上來講，出Core意味著當前進程存在BUG，需要程序員修復。從深層次的原因上講，是當前進程觸犯了某些OS層級的保護機制，逼迫OS向當前進程發送諸如SIGSEGV(即signal 11)之類的信號, 例如訪問空指針或數組越界出Core，實際上是觸犯了OS的內存管理，訪問了非當前進程的內存空間，OS需要通過出Core來進行警示，這就好像一個人身體內存在病毒，免疫系統就會通過發熱來警示，並導致人體發燒是一個道理（有意思的是，並不是每次數組越界都會出Core，這和OS的內存管理中虛擬頁面分配大小和邊界有關，即使不出Core，也很有可能讀到臟數據，引起後續程序行為紊亂，這是一種很難追查的BUG）。
說了這些，似乎感覺Core很強勢，讓人感覺缺乏控制力，其實不然。控制Core產生的行為和方式，有兩個途徑：
1.修改/proc/sys/kernel/core_pattern文件，此文件用於控制Core文件產生的文件名，默認情況下，此文件內容只有一行內容：「core」，此文件支持定製，一般使用%配合不同的字元，這里羅列幾種：
%p 出Core進程的PID
%u 出Core進程的UID
%s 造成Core的signal號
%t 出Core的時間，從1970-01-0100:00:00開始的秒數
%e 出Core進程對應的可執行文件名
2.Ulimit –C命令，此命令可以顯示當前OS對於Core文件大小的限制，如果為0，則表示不允許產生Core文件。如果想進行修改，可以使用：
Ulimit –cn
其中n為數字，表示允許Core文件體積的最大值，單位為Kb，如果想設為無限大，可以執行：
Ulimit -cunlimited
產生了Core文件之後，就是如何查看Core文件，並確定問題所在，進行修復。為此，我們不妨先來看看Core文件的格式，多了解一些Core文件。
4. core文件如何查看和調試
在Unix系統下，應用程序崩潰，一般會產生core文件，如何根據core文件查找問題的所在，並做相應的分析和調試，是非常重要的，本文對此做簡單介紹。
例如，一個程序cmm_test_tool在運行的時候發生了錯誤，並生成了一個core文件，如下:
-rw-r–r– 1 root cmm_test_tool.c
-rw-r–r– 1 root
cmm_test_tool.o
-rwxr-xr-x 1 root cmm_test_tool
-rw--- 1 root
core.19344
-rw--- 1 root core.19351
-rw-r–r– 1 root
cmm_test_tool.cfg
-rw-r–r– 1 root cmm_test_tool.res
-rw-r–r– 1 root
cmm_test_tool.log
[root@AUTOTEST_SIM2 mam2cm]#
就可以利用命令gdb進行查找，參數一是應用程序的名稱，參數二是core文件，運行
gdb
cmm_test_tool core.19344結果如下:
[root@AUTOTEST_SIM2 mam2cm]# gdb cmm_test_tool core.19344
GNU gdb Red Hat
Linux (5.2.1-4)
Copyright 2002 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
ing」 to see the conditions.
There is absolutely no warranty for GDB. Type
「show warranty」 for details.
This GDB was configured as
「i386-redhat-linux」…
Core was generated by `./cmm_test_tool』.
Program
terminated with signal 11, Segmentation fault.
Reading symbols from
/lib/i686/libpthread.so.0…done.
Loaded symbols for
/lib/i686/libpthread.so.0
Reading symbols from
/lib/i686/libm.so.6…done.
Loaded symbols for /lib/i686/libm.so.6
Reading
symbols from /usr/lib/libz.so.1…done.
Loaded symbols for
/usr/lib/libz.so.1
Reading symbols from
/usr/lib/libstdc++.so.5…done.
Loaded symbols for
/usr/lib/libstdc++.so.5
Reading symbols from
/lib/i686/libc.so.6…done.
Loaded symbols for /lib/i686/libc.so.6
Reading
symbols from /lib/libgcc_s.so.1…done.
Loaded symbols for
/lib/libgcc_s.so.1
Reading symbols from /lib/ld-linux.so.2…done.
Loaded
symbols for /lib/ld-linux.so.2
Reading symbols from
/lib/libnss_files.so.2…done.
Loaded symbols for /lib/libnss_files.so.2
#0
0×4202cec1 in __strtoul_internal () from
/lib/i686/libc.so.6
(gdb)
進入gdb提示符，輸入where，找到錯誤發生的位置和堆棧，如下:
(gdb) where
#0 0×4202cec1 in __strtoul_internal () from
/lib/i686/libc.so.6
#1 0×4202d4e7 in strtoul () from
/lib/i686/libc.so.6
#2 0×0804b4da in GetMaxIDFromDB (get_type=2,
max_id=0×806fd20) at cmm_test_tool.c:788
#3 0×0804b9d7 in ConstrctVODProgram
(vod_program=0×40345bdc) at cmm_test_tool.c:946
#4 0×0804a2f4 in
TVRequestThread (arg=0×0) at cmm_test_tool.c:372
#5 0×40021941 in
pthread_start_thread () from /lib/i686/libpthread.so.0
(gdb)
至此，可以看出文件出錯的位置是函數 GetMaxIDFromDB
，兩個參數分別是2和0×806fd20，這個函數位於源代碼的788行，基於此，我們就可以有針對性的找到問題的根源，並加以解決。