linux core dump

http://www.skycrack.com/tech/core_dump_analysis.html core dump intro with linux source code

http://www.gnu.org/software/gdb/documentation/

http://www.zedware.org/code/code-coredump.html get started with core dump analysis

John:  When you see the stack trace, you will be able to understand why core was dumped.  And then I will give another small exercise

(gdb) bt
#0  0x2acf5134 in *__GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#1  0x2acf6cbc in *__GI_abort () at ../sysdeps/generic/abort.c:88
#2  0x004626fc in AssertErrorHandler (
    exp=0x516c74 "GETDISKSET().isMirroredMode() || GETDISKSET().isParityRaidMode() || GETDISKSET().isHWRaidMode()", file=0x7fff72b8 "", line=6140)
    at /home/da/dev.ws.jadams.sn.hedorah-20110919/unity/m34/uServer/MSmain.cpp:4796
#3  0x00461214 in initializeServerDisks (flags=1, chunkPof2=19, 
    memSize=0x7fff79a0)
    at /home/da/dev.ws.jadams.sn.hedorah-20110919/unity/m34/uServer/MSmain.cpp:6140
#4  0x00467010 in MSServerMain () at MSglue.h:1998
#5  0x00467ecc in main (argc=1, argv=0xffffffff)
    at /home/da/dev.ws.jadams.sn.hedorah-20110919/unity/m34/uServer/MSmain.cpp:989
Current language:  auto; currently c

(gdb) bt full
#0  0x2acf5134 in *__GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
        result_var = 2022
        pd = (struct pthread *) 0x7e6
        pid = 2022
        selftid = 2022
#1  0x2acf6cbc in *__GI_abort () at ../sysdeps/generic/abort.c:88
        act = {sa_flags = 0, __sigaction_handler = {sa_handler = 0x7fff7048, 
    sa_sigaction = 0x7fff7048}, sa_mask = {__val = {2147446648, 715853140, 
      4259572, 6788756, 4226352, 2147446704, 716179728, 0, 715919816, 0, 0, 1, 
      4294967295, 4294967295, 716210176, 1163150409, 718068724, 715916960, 
      1769164137, 1920102258, 4294967295, 4294967295, 545029152, 1195725892, 
      4294967295, 4294967295, 796287346, 795635559, 4294967295, 4294967295, 
      1818582867, 1161191218}}, sa_restorer = 0, sa_resv = {-1}}
        sigs = {__val = {32, 0 <repeats 31 times>}}
#2  0x004626fc in AssertErrorHandler (
    exp=0x516c74 "GETDISKSET().isMirroredMode() || GETDISKSET().isParityRaidMode() || GETDISKSET().isHWRaidMode()", file=0x7fff72b8 "", line=6140)
    at /home/da/dev.ws.jadams.sn.hedorah-20110919/unity/m34/uServer/MSmain.cpp:4796
        buf = "  ASSERT: pid 2022 file /home/da/dev.ws.jadams.sn.hedorah-20110919/unity/m34/uServer/MSmain.cpp line 6140:  GETDISKSET().isMirroredMode() || GETDISKSET().isParityRaidMode() || GETDISKSET().isHWRaidMod"...
        asserted = 1
#3  0x00461214 in initializeServerDisks (flags=1,chunkPof2=19, 
    memSize=0x7fff79a0)
    at /home/da/dev.ws.jadams.sn.hedorah-20110919/unity/m34/uServer/MSmain.cpp:6140
        partSize = The value of variable 'partSize' is distributed across several
locations, and GDB cannot access its value.

排除法：

1. cunkPof2=19, 2exp19=512K, OK!

2. 0x7fff79a0~=0x80000000=2G, OK!

3. partSize

1. initializeServerDisks(ServerInitFlags flags, int32u chunkPof2, ByteCount64* memSize)

2. if ( msInitializing )
{
......
GETDISKSET().buildInitialSet(chunkPof2, targetType);
}

3.

  ASSERT: pid 1918 file /home/evan/commcode/dev.ws.Warlock.CommonCode_Fix_Team_CleanBuild/unity/m34/uServer/MSmain.cpp line 6140:  GETDISKSET().isMirroredMode() || GETDISKSET().isParityRaidMode() || GETDISKSET().isHWRaidMode()

    def create_storage_group(self, group_name, storage_list, protection):
        """
      ........
               
        self.__construct_request('ModifyStorageGroupDetails', False, original_xml + modified_xml)
        
        

Danny classic:

1. void initializeServerDisks(..): --  SC_ASSERT(GETDISKSET().isMirroredMode() || GETDISKSET().isParityRaidMode() || GETDISKSET().isHWRaidMode());

2. MSServerMain() -- initializeServerDisks(..)

09-29

Is this the symbol file I need?

\output\isis_mips_linux_mv40_Debug\m34\uServer

file name: uServerd

What I got is not good:

warning: exec file is newer than core file.

Reading symbols.....done.

Cannot access memory at address 0x2acf5130

idea: At least I can try to run this binary file in micro server.

John Adams：

1.Then you can create a timestamp stream in accurev for the specified time and date.  If you setBUILDTYPE=Debug and build this stream, you will then have a symbol file (which is the actual binary with special records).  

Also, you canextract thelogBuffer from a corefile via the gdb dump command.

2.messages or ioLogFile in conjunction with theuServerd.lisfile which can be found in the isb installer tgz.

3. If there was a segv or something, you may get this in ioLogFile and/or messages. 

4. Most of the gnu toolchain is documented viainfo files. 

5. The appropriate gdb is the one compiled to run on intel but assume ourmips target by default. 

6. As a final comment, most development work (and muchsqa work) should be done withheartbeat off.  This is setup in the switchagent basic page and controls whether isb's are automatically rebooted when the userver asserts.

question 1: where is the ".out" (executable file)?

qusetion 2: install gdb inisb?

1、GNU C编译器（即GCC）

gcc -v ：GCC版本

-c：仅把源代友编译为目标代码；

-s：GCC在为C代码产生了汇编语言文件后，就停止编译。GCC产生的汇编语言文件的缺省扩展名为.s。

-E：指示编译器仅对输入文件进行预处理。此时，预处理器的输出被送到标准输出（如显示器）而不是储存在文件里。

-O：GCC对源码进行基本优化。

-O2：GCC产生尽可能小和尽可能快的代码

-g选项告诉GCC产生能被GNU调试器（如gdb）使用的调试信息，以便调试用户的程序。

-pg选项告诉GCC在用户的程序里加入额外的代码，执行时，产生gporf用的剖析信息以显示程序的耗时情况。

gcc info page：详细GCC编译器参数的说明，在Emacs内，按下C－hi，然后选“gcc”的选项。

2、使用gdb：

gdb filename：能直接指定想要调试的程序。也可用gdb去检查一个因程序异常终止而产生的core文件，或者与一个正在运行的程序相连。

（1）为使gdb正常工作，必须使程序在编译时包含调试信息。调试信息包含程序里的每个变量的类型、在可执行文件里的地址映射以及源代码的行号。

（2）gdb命令一览：

file：装入想要调试的可执行文件

kill：终止正在调试的程序；

list：列出产生执行文件的源代码的一部分

next：执行一行源代码但不进入函数内部；

step：执行一行源代码而且进入函数内部；

run：执行当前被调试的程序；

quit：终止gdb

watch：能监视一个变量的值 而不管它何时被改变；

print：显示表达示的值；

break：在代码里设置断点，这将使程序执行到这里时被挂起；

make：不退出gdb就可以重新产生可执行文件

shell：不离开gdb就执行UNIX shell命令

用gdb查看core文件:

下面我们可以在发生运行时信号引起的错误时发生core dump了.
发生core dump之后,用gdb进行查看core文件的内容,以定位文件中引发core dump的行.
gdb [exec file] [core file]
如: gdb ./test test.core
在进入gdb后,用bt命令查看backtrace以检查发生程序运行到哪里,

来定位core dump的文件->行.

15862420036

coredump简介与coredump原因总结

来源:www.solarisman.cn  作者:solarisman  点击:2367次

什么是coredump？

通常情况下coredmp包含了程序运行时的内存，寄存器状态，堆栈指针，内存管理信息等。可以理解为把程序工作的当前状态存储成一个文件。许多程序和操作系统出错时会自动生成一个core文件。

如何使用coredump?

coredump可以用在很多场合，使用Linux,或者solaris的人可能都有过这种经历，系统在跑一些压力测试或者系统负载一大的话，系统就hang住了或者干脆system panic.这时唯一能帮助你分析和解决问题的就是coredump了。

现在很多应该程序出错时也会出现coredump.

分析coredump的工具

现在大部分类unix操作系统都提供了分析core文件的工具，比如 GNU Binutils Binary File Descriptor library (BFD), GNU Debugger (gdb），mdb等

coredump的文件格式

类unix操作系统中使用efi格式保存coredump文件。

在solairs下

bash-3.2# file *unix.3 ELF 32-bit LSB executable 80386 Version 1, statically linked, not stripped, no debugging information availableunix.4 ELF 32-bit LSB executable 80386 Version 1, statically linked, not stripped, no debugging information available

造成程序coredump的原因很多，这里根据以往的经验总结一下：

1 内存访问越界
  a) 由于使用错误的下标，导致数组访问越界
  b) 搜索字符串时，依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符
  c) 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串操作函数，将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。
 
2 多线程程序使用了线程不安全的函数。
应该使用下面这些可重入的函数，尤其注意红色标示出来的函数，它们很容易被用错：
asctime_r(3c) gethostbyname_r(3n) getservbyname_r(3n) ctermid_r(3s) gethostent_r(3n) getservbyport_r(3n) ctime_r(3c) getlogin_r(3c) getservent_r(3n) fgetgrent_r(3c) getnetbyaddr_r(3n) getspent_r(3c) fgetpwent_r(3c) getnetbyname_r(3n) getspnam_r(3c) fgetspent_r(3c) getnetent_r(3n) gmtime_r(3c) gamma_r(3m) getnetgrent_r(3n) lgamma_r(3m) getauclassent_r(3) getprotobyname_r(3n) localtime_r(3c) getauclassnam_r(3) etprotobynumber_r(3n) nis_sperror_r(3n) getauevent_r(3) getprotoent_r(3n) rand_r(3c) getauevnam_r(3) getpwent_r(3c) readdir_r(3c) getauevnum_r(3) getpwnam_r(3c) strtok_r(3c) getgrent_r(3c) getpwuid_r(3c) tmpnam_r(3s) getgrgid_r(3c) getrpcbyname_r(3n) ttyname_r(3c) getgrnam_r(3c) getrpcbynumber_r(3n) gethostbyaddr_r(3n) getrpcent_r(3n)
 
3 多线程读写的数据未加锁保护。
对于会被多个线程同时访问的全局数据，应该注意加锁保护，否则很容易造成core dump
 
4 非法指针
  a) 使用空指针
  b) 随意使用指针转换。一个指向一段内存的指针，除非确定这段内存原先就分配为某种结构或类型，或者这种结构或类型的数组，否则不要将它转换为这种结构或类型的指针，而应该将这段内存拷贝到一个这种结构或类型中，再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的，那么访问它时就很容易因为bus error而core dump.
 
5 堆栈溢出
不要使用大的局部变量（因为局部变量都分配在栈上），这样容易造成堆栈溢出，破坏系统的栈和堆结构，导致出现莫名其妙的错误。