1.查找到系统程序崩溃时产生的core文件：
[root@rac1 ~]# find /u01 -name core.* -exec ls -lthr {} \
-rw------- 1 root root 480M Sep 27 12:01 /u01/oracle/product/crs/log/rac1/crsd/core.3907
core文件大小为480M，文件还挺大的。所以，平时，如果遇到磁盘空间不足的时候，没准就是core文件在做怪呢！
2.定位出是由于哪个文件产生的core文件：
[root@rac1 ~]# find /u01 -name core.* -exec ls -lthr {} \|awk '{print $9}'|xargs file/u01/oracle/product/crs/log/rac1/crsd/core.3907: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'crsd.bin'
由以下命令，可以看出core.3907的产生，是由于'crsd.bin'文件引起的。
3.使用gdb对core进行追踪：
[root@rac1 ~]# gdb /u01/oracle/product/crs/bin/crsd.bin /u01/oracle/product/crs/log/rac1/crsd/core.3907GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
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 "i386-redhat-linux-gnu"...
warning: Can't read pathname for load map: Input/output error.
warning: .dynamic section for "/lib/libdl.so.2" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /u01/oracle/product/crs/lib/libocr10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libocr10.so
Reading symbols from /u01/oracle/product/crs/lib/libocrb10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libocrb10.so
Reading symbols from /u01/oracle/product/crs/lib/libocrutl10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libocrutl10.so
Reading symbols from /u01/oracle/product/crs/lib/libhasgen10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libhasgen10.so
Reading symbols from /u01/oracle/product/crs/lib/libclntsh.so.10.1...done.
Loaded symbols for /u01/oracle/product/crs/lib/libclntsh.so.10.1
Reading symbols from /u01/oracle/product/crs/lib/libskgxn2.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libskgxn2.so
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /usr/lib/libstdc++.so.5...done.
Loaded symbols for /usr/lib/libstdc++.so.5
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
Reading symbols from /u01/oracle/product/crs/lib/libnnz10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libnnz10.so
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `/u01/oracle/product/crs/bin/crsd.bin reboot'.
Program terminated with signal 6, Aborted.
[New process 4787]
[New process 4789]
[New process 4786]
[New process 4785]
[New process 4784]
[New process 4783]
[New process 4782]
[New process 4781]
[New process 4780]
[New process 4779]
[New process 4778]
[New process 4721]
[New process 4701]
[New process 4700]
[New process 4665]
[New process 4664]
[New process 4663]
[New process 4662]
[New process 4661]
[New process 4660]
[New process 4659]
[New process 4658]
[New process 4657]
[New process 4656]
[New process 4655]
[New process 4654]
[New process 4653]
[New process 4652]
[New process 4651]
[New process 4650]
[New process 4649]
[New process 4648]
[New process 4647]
[New process 4641]
[New process 4640]
[New process 4639]
[New process 4638]
[New process 4637]
[New process 4636]
[New process 4635]
[New process 4634]
[New process 4514]
[New process 3907]
#0 0x00389402 in __kernel_vsyscall ()
(gdb) where
#0 0x00389402 in __kernel_vsyscall ()
#1 0x009a1df0 in raise () from /lib/libc.so.6
#2 0x009a3701 in abort () from /lib/libc.so.6
#3 0x0099b26b in __assert_fail () from /lib/libc.so.6
#4 0x08363c8e in destr_detour5 () at clsThreadMain.cpp:70
#5 0x00af45ab in start_thread () from /lib/libpthread.so.0
#6 0x00a4acfe in clone () from /lib/libc.so.6
(gdb)
注意：上面的两行红色部分：
Core was generated by `/u01/oracle/product/crs/bin/crsd.bin reboot'.
Program terminated with signal 6, Aborted.
恰恰说明，由于系统发生reboot重启 *** 作，而产生了core文件。
oracle 产生core文件
xyk欠款3万以上还不上，12月14日最新逾期政策调整，联系我们
xyk网贷逾期处理
广告
Oracle Core- Essential Internals for DBAs and Developers 无水印pdf
25下载·0评论
2017年9月29日
oracle数据库原理基本知识点,ORACLE数据库基础知识1.doc
108阅读·0评论·0点赞
2021年5月7日
浅谈Core文件分析
6248阅读·0评论·0点赞
2014年7月23日
执行oracle命令时core,oracle coredump
135阅读·0评论·0点赞
2021年5月4日
oracle core文件使用率,Oracle EBS$INST_TOP/ora/10.1.2/forms存在很多core.*文件
165阅读·0评论·0点赞
2021年5月1日
不断有core文件在$ORACLE_HOME/dbs目录产生
3149阅读·0评论·0点赞
2014年1月21日
无锡xyk还不上了，不想连累家人，联系我们帮您
全国逾期处理中心
广告
oracle目录下core文件是什么,学习猿地-oracle core 概述
298阅读·0评论·0点赞
2021年5月2日
oracle core文件使用率,不断有core文件在$ORACLE_HOME/dbs目录产生
221阅读·0评论·0点赞
2021年4月3日
oracle目录下core文件是什么,oracle中adump,bdump,dpdump,udump目录中一些内容的作用
270阅读·0评论·0点赞
2021年5月2日
oracle 产生core文件,11.2.0.3 AIX RAC下$ORACLE_HOME/dbs生成大量core_* dump文件
181阅读·0评论·0点赞
2021年5月8日
linux core 调试 gdb,gdb core 调试_gdb coredump 调试_linux gdb core 调试(3)
159阅读·0评论·0点赞
2021年5月26日
软件测试解决Oracle问题,如何快速解决Oracle数据库中的常见问题
39阅读·0评论·0点赞
2021年5月4日
core文件截断的处理方法
4949阅读·0评论·0点赞
2012年2月10日
oracle设置core文件大小,Linux的Core文件设置与调试
488阅读·0评论·0点赞
2021年5月5日
oracle core文件使用率,oracle core dump 分析 - Oracle数据库管理 - Oracle数据库数据恢复、性能优化来问问AskMaclean - ParnassusDat...
190阅读·0评论·0点赞
2021年5月1日
GDB Core
651阅读·0评论·0点赞
2013年10月31日
Oracle core读书笔记
1735阅读·0评论·1点赞
2022年2月18日
oracle目录下core文件是什么,AIX上Oracle RAC 11g r2不断产生core文件问题的解决
98阅读·0评论·0点赞
2021年5月2日
Core文件产生以及调试
295阅读·0评论·0点赞
2021年9月24日
去首页
看看更多热门内容
在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
copying” 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行，基于此，我们就可以有针对性的找到问题的根源，并加以解决。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）