ORACLE RAC－－在Linux下测试产生并调试core文件

1.查看服务器内核版本：

[oracle@rac1 ~]$ uname -a 
Linux rac1 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux

再看看默认的一些参数，注意core file size是个0，程序出错时不会产生core文件了。

[oracle@rac1 ~]$ ulimit -a 
core file size (blocks, -c) 0 
data seg size (kbytes, -d) unlimited 
scheduling priority (-e) 0 
file size (blocks, -f) unlimited 
pending signals (-i) 16384 
max locked memory (kbytes, -l) 32 
max memory size (kbytes, -m) unlimited 
open files (-n) 4096 
pipe size (512 bytes, -p) 8 
POSIX message queues (bytes, -q) 819200 
real-time priority (-r) 0 
stack size (kbytes, -s) 10240 
cpu time (seconds, -t) unlimited 
max user processes (-u) 2047 
virtual memory (kbytes, -v) unlimited 
file locks (-x) unlimited

2. 写个简单的程序，看看core文件是不是会被产生。

[oracle@rac1 ~]$ cat test.c

#include <stdio.h> 
#include <stdlib.h>

static void sub(void); 
int main(void) 
{ 
sub(); 
return 0; 
}

static void sub(void) 
{ 
int *p = NULL; 
/* derefernce a null pointer, expect core dump. */ 
printf("%d", *p); 
}

[oracle@rac1 ~]$ gcc -o test -g test.c //加上-g参数，便于使用gdb调试器 
[oracle@rac1 ~]$ time ./test 
Segmentation fault

real 0m0.004s 
user 0m0.000s 
sys 0m0.003s

[oracle@rac1 CR_TEST]$ ls -l core.* 
ls: core.*: No such file or directory

没有找到core文件，我们改改ulimit的设置，让它产生。1024是随便取的，要是core文件大于1024个块，就产生不出来了。

[oracle@rac1 ~]$ ulimit -c 1024

[oracle@rac1 CR_TEST]$ ulimit -a 
core file size (blocks, -c) 1024 
data seg size (kbytes, -d) unlimited 
scheduling priority (-e) 0 
file size (blocks, -f) unlimited 
pending signals (-i) 16384 
max locked memory (kbytes, -l) 32 
max memory size (kbytes, -m) unlimited 
open files (-n) 4096 
pipe size (512 bytes, -p) 8 
POSIX message queues (bytes, -q) 819200 
real-time priority (-r) 0 
stack size (kbytes, -s) 10240 
cpu time (seconds, -t) unlimited 
max user processes (-u) 2047 
virtual memory (kbytes, -v) unlimited 
file locks (-x) unlimited

[oracle@rac1 CR_TEST]$ ./test 
Segmentation fault (core dumped) 
[oracle@rac1 CR_TEST]$ ls -l core.* 
-rw------- 1 oracle oinstall 139264 Sep 27 13:35 core.29664

由上述的输出信息，可以看到多了个(core dumped)。确实产生了一个core文件，29664是该进程的PID。我们用GDB来看看这个core。

3.使用gdb命令调试：

[oracle@rac1 CR_TEST]$ gdb --core=core.29664 
GNU gdb Fedora (6.8-37.el5) 
Copyright (C) 2008 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 
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". 
(no debugging symbols found) 
Core was generated by `./test'. 
Program terminated with signal 11, Segmentation fault. 
[New process 29664] 
#0 0x080483b8 in ?? () 
(gdb) bt 
#0 0x080483b8 in ?? () 
#1 0x00ab9ff4 in ?? () 
#2 0x00ab8204 in ?? () 
#3 0xbf8d6198 in ?? () 
#4 0x080483f9 in ?? () 
#5 0x009a4e25 in ?? () 
#6 0x00000000 in ?? ()

此时使用bt看不到backtrace，也就是调用堆栈，原来GDB还不知道符号信息在哪里。需要指定文件位置：

(gdb) file ./test 
Reading symbols from /home/oracle/CR_TEST/test...done. 
(gdb) bt 
#0 0x080483b8 in sub () at test.c:15 
#1 0x0804839a in main () at test.c:7

此时backtrace出来了。

(gdb) l 12 
7 sub(); 
8 return 0; 
9 } 
10 
11 static void sub(void) 
12 { 
13 int *p = NULL; 
14 /* derefernce a null pointer, expect core dump. */ 
15 printf("%d", *p); 
16 }

 

以上测试过程，即为在RAC节点上测试产生并调试core文件的全过程。

     本文转自vcdog 51CTO博客，原文链接：http://blog.51cto.com/255361/837517，如需转载请自行联系原作者