tomcatcore文件分析|linux core 文件 怎么分析

|

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.19344GNU 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 arewelcome 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.0Reading symbols from /lib/i686/libm.so.6…done.Loaded symbols for /lib/i686/libm.so.6Reading symbols from /usr/lib/libz.so.1…done.Loaded symbols for /usr/lib/libz.so.1Reading symbols from /usr/lib/libstdc++.so.5…done.Loaded symbols for /usr/lib/libstdc++.so.5Reading symbols from /lib/i686/libc.so.6…done.Loaded symbols for /lib/i686/libc.so.6Reading symbols from /lib/libgcc_s.so.1…done.Loaded symbols for /lib/libgcc_s.so.1Reading symbols from /lib/ld-linux.so.2…done.Loaded symbols for /lib/ld-linux.so.2Reading 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行,基于此,我们就可以有针对性的找到问题的根源,并加以解决。


赞 (0)