Linux下的 GDB调试 【在线sample程序--&&--离线sample程序】

参考：http://blog.youkuaiyun.com/xiaofei0859/article/details/5649057

           http://blog.youkuaiyun.com/haoel/article/details/2879

一、GDB 调试方法

一）、GDB的静态调试启动方法:

1、当需要在命令行通过gdb来启动可执行程序的时候,可使用一下命令:
   gdb <可执行程序名>
   这个时候gdb会加载可执行程序的符号表和堆栈,并为启动程序作好准备;

   接下来,需要设置可执行程序的命令行参数:
   set args <参数列表>

   然后设置断点: b或break;

   最后通过命令r或run来启动程序,或者通过c或continue命令来继续已经被暂停的程序;

2、当程序core的时候,需要查看core文件的内容,可以使用以下方式:

      gdb <可执行程序名> <core文件名>

      这个时候, gdb会结合可执行程序的符号   和  堆栈来查看core文件内容,以分析程序在core掉时的内存影象;

二）、GDB的动态调试启动方法:

   动态调试就是在不终止正在运行的进程的情况下来对这个正在运行的进程进行调试;其启动方式有两种:

   方式一:
   gdb <可执行程序名> <进程ID>
   比如: gdb <可执行程序名> 1234
   这条命令会把进程ID为1234的进程与gdb联系起来,也就是说,这条命令会把进程ID为1234的进程的地址空间附着在gdb的地址空间中,然后使这个进程在gdb的环境下运行,这样的话,gdb就可以清楚地了解该进程的执行情况、函数堆栈、内存使用情况,等等;

   方式二:
   直接在gdb中把一个正在运行的进程连接到gdb中,以便于进行动态调试;使用attach命令:
   attach  <进程ID>
   当使用attach命令时,你应该先使用file命令来指定进程所联系的程序源代码和符号表;当gdb接到attach命令后的第一件事情就是停止进程的运行,你可以使用所有gdb的命令来调试一个已"连接"到gdb的进程,这就像你使用run/r命令在gdb中启动它一样.如果你要进程继续运行,那么,可以使用continue/c命令就可以了;
   detach:
   当你调试结束之后,可以使用该命令断开进程与gdb的连接(结束gdb对进程的控制),在这个命令执行之后,你所调试的那个进程将继续运行;
   如果你在使用attach命令把一个正在运行的进程连接到gdb之后又退出了gdb,或者是使用run/r命令执行了另外一个进程,那么刚才那个被连接到gdb的进程将会因为收到一个kill命令而退出;
   如果要使用attach命令,你的操作系统环境就必须支持进程;另外,你还需要有向进程发送信号的权力;
   使用attach命令的例子:
   gdb
   file <可执行程序名>   #指定进程所关联的程序源代码和符号表
   attach <进程ID>
   .....
   使用gdb的命令进行调试;
   .....
   detach     #调试结束,解除进程与gdb的连接,使进程继续运行;

二、GDB 调试实例

一个调试示例
——————

源程序：tst.c

     1 #include <stdio.h>
     2
     3 int func(int n)
     4 {
     5         int sum=0,i;
     6         for(i=0; i<n; i++)
     7         {
     8                 sum+=i;
     9         }
    10         return sum;
    11 }
    12
    13
    14 main()
    15 {
    16         int i;
    17         long result = 0;
    18         for(i=1; i<=100; i++)
    19         {
    20                 result += i;
    21         }
    22
    23        printf("result[1-100] = %d /n", result );
    24        printf("result[1-250] = %d /n", func(250) );
    25 }

编译生成执行文件：（Linux下）
    hchen/test> cc -g tst.c -o tst

使用GDB调试：

hchen/test> gdb tst  <---------- 启动GDB
GNU gdb 5.1.1
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-suse-linux"...
(gdb) l     <-------------------- l命令相当于list，从第一行开始例出原码。
1        #include <stdio.h>
2
3        int func(int n)
4        {
5                int sum=0,i;
6                for(i=0; i<n; i++)
7                {
8                        sum+=i;
9                }
10               return sum;
(gdb)       <-------------------- 直接回车表示，重复上一次命令
11       }
12
13
14       main()
15       {
16               int i;
17               long result = 0;
18               for(i=1; i<=100; i++)
19               {
20                       result += i;   
(gdb) break 16    <-------------------- 设置断点，在源程序第16行处。
Breakpoint 1 at 0x8048496: file tst.c, line 16.
(gdb) break func  <-------------------- 设置断点，在函数func()入口处。
Breakpoint 2 at 0x8048456: file tst.c, line 5.
(gdb) info break  <-------------------- 查看断点信息。
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x08048496 in main at tst.c:16
2   breakpoint     keep y   0x08048456 in func at tst.c:5
(gdb) r           <--------------------- 运行程序，run命令简写
Starting program: /home/hchen/test/tst

Breakpoint 1, main () at tst.c:17    <---------- 在断点处停住。
17               long result = 0;
(gdb) n          <--------------------- 单条语句执行，next命令简写。
18               for(i=1; i<=100; i++)
(gdb) n
20                       result += i;
(gdb) n
18               for(i=1; i<=100; i++)
(gdb) n
20                       result += i;
(gdb) c          <--------------------- 继续运行程序，continue命令简写。
Continuing.
result[1-100] = 5050       <----------程序输出。

Breakpoint 2, func (n=250) at tst.c:5
5                int sum=0,i;
(gdb) n
6                for(i=1; i<=n; i++)
(gdb) p i        <--------------------- 打印变量i的值，print命令简写。
$1 = 134513808
(gdb) n
8                        sum+=i;
(gdb) n
6                for(i=1; i<=n; i++)
(gdb) p sum
$2 = 1
(gdb) n
8                        sum+=i;
(gdb) p i
$3 = 2
(gdb) n
6                for(i=1; i<=n; i++)
(gdb) p sum
$4 = 3
(gdb) bt        <--------------------- 查看函数堆栈。
#0  func (n=250) at tst.c:5
#1  0x080484e4 in main () at tst.c:24
#2  0x400409ed in __libc_start_main () from /lib/libc.so.6
(gdb) finish    <--------------------- 退出函数。
Run till exit from #0  func (n=250) at tst.c:5
0x080484e4 in main () at tst.c:24
24              printf("result[1-250] = %d /n", func(250) );
Value returned is $6 = 31375
(gdb) c     <--------------------- 继续运行。
Continuing.
result[1-250] = 31375    <----------程序输出。

Program exited with code 027. <--------程序退出，调试结束。
(gdb) q     <--------------------- 退出gdb。
hchen/test>

好了，有了以上的感性认识，还是让我们来系统地认识一下gdb吧。

三、GDB使用

1.使用GDB
————

    1)----一般来说GDB主要调试的是C/C++的程序。要调试C/C++的程序，首先在编译时，我们必须要把调试信息加到可执行文件中。使用编译器（cc/gcc/g++）的 -g 参数可以做到这一点。如：

    > cc -g hello.c -o hello
    > g++ -g hello.cpp -o hello

如果没有-g，你将看不见程序的函数名、变量名，所代替的全是运行时的内存地址。当你用-g把调试信息加入之后，并成功编译目标代码以后，让我们来看看如何用gdb来调试他。

    2)----启动GDB的方法有以下几种：

    1、gdb <program>
       program也就是你的执行文件，一般在当然目录下。

    2、gdb <program> core
       用gdb同时调试一个运行程序和core文件，core是程序非法执行后core dump后产生的文件。

    3、gdb <program> <PID>
       如果你的程序是一个服务程序，那么你可以指定这个服务程序运行时的进程ID。gdb会自动attach上去，并调试他。program应该在PATH环境变量中搜索得到。

 

    3)----GDB启动时，可以加上一些GDB的启动开关，详细的开关可以用gdb -help查看。我在下面只例举一些比较常用的参数：

    -symbols <file>
    -s <file>
    从指定文件中读取符号表。

    -se file
    从指定文件中读取符号表信息，并把他用在可执行文件中。

    -core <file>
    -c <file>
    调试时core dump的core文件。

    -directory <directory>
    -d <directory>
    加入一个源文件的搜索路径。默认搜索路径是环境变量中PATH所定义的路径。

2. GDB的命令概貌
———————

    启动gdb后，就你被带入gdb的调试环境中，就可以使用gdb的命令开始调试程序了，gdb的命令可以使用help命令来查看，如下所示：

    tonylau@tonylau-OptiPlex-780:~$gdb
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 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 "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.
(gdb) help
List of classes of commands:

aliases -- Aliases of other commands
breakpoints -- Making program stop at certain points
data -- Examining data
files -- Specifying and examining files
internals -- Maintenance commands
obscure -- Obscure features
running -- Running the program
stack -- Examining the stack
status -- Status inquiries
support -- Support facilities
tracepoints -- Tracing of program execution without stopping the program
user-defined -- User-defined commands

Type "help" followed by a class name for a list of commands in that class.
Type "help all" for the list of all commands.
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) help aliases
Aliases of other commands.

List of commands:

ni -- Step one instruction
rc -- Continue program being debugged but run it in reverse
rni -- Step backward one instruction
rsi -- Step backward exactly one instruction
si -- Step one instruction exactly
stepping -- Specify single-stepping behavior at a tracepoint
tp -- Set a tracepoint at specified line or function
tty -- Set terminal for future runs of program being debugged
where -- Print backtrace of all stack frames
ws -- Specify single-stepping behavior at a tracepoint

Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb)

   示例一：在进入函数func时，设置一个断点。可以敲入break func，或是直接就是b func
    (gdb) b func
    Breakpoint 1 at 0x8048458: file hello.c, line 10.
 
    示例二：敲入b按两次TAB键，你会看到所有b打头的命令：
    (gdb) b
    backtrace  break      bt
    (gdb)

    示例三：只记得函数的前缀，可以这样：
    (gdb) b make_ <按TAB键>
    （再按下一次TAB键，你会看到:）
    make_a_section_from_file     make_environ
    make_abs_section             make_function_type
    make_blockvector             make_pointer_type
    make_cleanup                 make_reference_type
    make_command                 make_symbol_completion_list
    (gdb) b make_
    GDB把所有make开头的函数全部例出来给你查看

3.GDB中运行UNIX的shell程序
————————————

    1).在gdb环境中，你可以执行UNIX的shell的命令，使用gdb的shell命令来完成：

    shell <command string>
    调用UNIX的shell来执行<command string>，环境变量SHELL中定义的UNIX的shell将会被用来执行<command string>，如果SHELL没有定义，那就使用UNIX的标准shell：/bin/sh。（在Windows中使用Command.com或cmd.exe）

    2).还有一个gdb命令是make：
    make <make-args>
    可以在gdb中执行make命令来重新build自己的程序。这个命令等价于“shell make <make-args>”。

 

4. 在GDB中运行程序
————————

    当以gdb <program>方式启动gdb后，gdb会在PATH路径和当前目录中搜索<program>的源文件。如要确认gdb是否读到源文件，可使用l或list命令，看看gdb是否能列出源代码。

在gdb中，运行程序使用r或是run命令。程序的运行，你有可能需要设置下面四方面的事。

1、程序运行参数。
    set args 可指定运行时参数。（如：set args 10 20 30 40 50）
    show args 命令可以查看设置好的运行参数。

2、运行环境。
    path <dir> 可设定程序的运行路径。
    show paths 查看程序的运行路径。
    set environment varname [=value] 设置环境变量。如：set env USER=hchen
    show environment [varname] 查看环境变量。

3、工作目录。
    cd <dir> 相当于shell的cd命令。
    pwd 显示当前的所在目录。

4、程序的输入输出。
    info terminal 显示你程序用到的终端的模式。
    使用重定向控制程序输出。如：run > outfile
    tty命令可以指写输入输出的终端设备。如：tty /dev/ttyb

5.调试已运行的程序
————————

两种方法：
1、在UNIX下用ps查看正在运行的程序的PID（进程ID），然后用gdb <program> PID格式挂接正在运行的程序。
2、先用gdb <program>关联上源代码，并进行gdb，在gdb中用attach命令来挂接进程的PID。并用detach来取消挂接的进程。

6.暂停 / 恢复程序运行
—————————

调试程序中，暂停程序运行是必须的，GDB可以方便地暂停程序的运行。你可以设置程序的在哪行停住，在什么条件下停住，在收到什么信号时停往等等。以便于你查看运行时的变量，以及运行时的流程。

当进程被gdb停住时，你可以使用info program 来查看程序的是否在运行，进程号，被暂停的原因。

在gdb中，我们可以有以下几种暂停方式：断点（BreakPoint）、观察点（WatchPoint）、捕捉点（CatchPoint）、信号（Signals）、线程停止（Thread Stops）。如果要恢复程序运行，可以使用c或是continue命令。

一、设置断点（BreakPoint）
   
    我们用break命令来设置断点。正面有几点设置断点的方法：
   
    break <function>
        在进入指定函数时停住。C++中可以使用class::function或function(type,type)格式来指定函数名。

    break <linenum>
        在指定行号停住。

    break +offset
    break -offset
        在当前行号的前面或后面的offset行停住。offiset为自然数。

    break filename:linenum
        在源文件filename的linenum行处停住。

    break filename:function
        在源文件filename的function函数的入口处停住。

    break *address
        在程序运行的内存地址处停住。

    break
        break命令没有参数时，表示在下一条指令处停住。

    break ... if <condition>
        ...可以是上述的参数，condition表示条件，在条件成立时停住。比如在循环境体中，可以设置break if i=100，表示当i为100时停住程序。

    查看断点时，可使用info命令，如下所示：（注：n表示断点号）
    info breakpoints [n]
    info break [n]
   

二、设置观察点（WatchPoint）
   
    观察点一般来观察某个表达式（变量也是一种表达式）的值是否有变化了，如果有变化，马上停住程序。我们有下面的几种方法来设置观察点：
   
    watch <expr>
        为表达式（变量）expr设置一个观察点。一量表达式值有变化时，马上停住程序。
       
    rwatch <expr>
        当表达式（变量）expr被读时，停住程序。
       
    awatch <expr>
        当表达式（变量）的值被读或被写时，停住程序。
   
    info watchpoints
        列出当前所设置了的所有观察点。

三、设置捕捉点（CatchPoint）

    你可设置捕捉点来补捉程序运行时的一些事件。如：载入共享库（动态链接库）或是C++的异常。设置捕捉点的格式为：
   
    catch <event>
        当event发生时，停住程序。event可以是下面的内容：
        1、throw 一个C++抛出的异常。（throw为关键字）
        2、catch 一个C++捕捉到的异常。（catch为关键字）
        3、exec 调用系统调用exec时。（exec为关键字，目前此功能只在HP-UX下有用）
        4、fork 调用系统调用fork时。（fork为关键字，目前此功能只在HP-UX下有用）
        5、vfork 调用系统调用vfork时。（vfork为关键字，目前此功能只在HP-UX下有用）
        6、load 或 load <libname> 载入共享库（动态链接库）时。（load为关键字，目前此功能只在HP-UX下有用）
        7、unload 或 unload <libname> 卸载共享库（动态链接库）时。（unload为关键字，目前此功能只在HP-UX下有用）

    tcatch <event>
        只设置一次捕捉点，当程序停住以后，应点被自动删除。

四、GDB CORE DUMP调试

     问题：有的程序可以通过编译,但在运行时会出现Segment fault(段错误).这通常都是指针错误引起的.

       解决方法：有一种办法是,我们用gdb的step,一步一步寻找.这放在短小的代码中是可行的,但要让你step一个上万行的代码,我想你会从此厌恶程序员这个名字,而把他叫做调试员.

                         我们还有更好的办法,这就是core file.

以下是我们详细的对Linux core dump的调试技术进行的介绍:

1.何谓 Linux core dump？

       我们在开发（或使用）一个程序时，最怕的就是程序莫明其妙地当掉。虽然系统没事，但我们下次仍可能遇到相同的问题。于是这时操作系统就会把程序当掉时的内存内容 dump出来，让我们或是debugger做为参考。这个动作就叫作 core dump。

       当程序运行的过程中异常终止或崩溃，操作系统会将程序当时的内存状态记录下来，保存在一个文件中，这种行为就叫做Core Dump（中文有的翻译成“核心转储”)。我们可以认为 core dump 是“内存快照”，但实际上，除了内存信息之外，还有些关键的程序运行状态也会同时 dump 下来，例如寄存器信息（包括程序指针、栈指针等）、内存管理信息、其他处理器和操作系统状态和信息。core dump 对于编程人员诊断和调试程序是非常有帮助的，因为对于有些程序错误是很难重现的，例如指针异常，而 core dump 文件可以再现程序出错时的情景。

2.why core,看出 core最好用的地方

      gdb -c core 进去后打 where,就可以 show出你是在程序哪一行当掉的,还有在当掉时在哪个 function里,这个 function是被哪个function所 call的,而这个 function又是被哪个function所 call的....一直到 main()由这个信息,可以找出五六成的 bug........屡试不爽,.

     但先决条件,当你在 compile时必须把 debug information的选项打开不然,就会出现一大堆你看不懂的东西，而不是你喜欢的源程序。

3.Core Dump 如何产生（refer：http://www.cnblogs.com/hazir/p/linxu_core_dump.html）--www.hazirguo.com

      上面说当程序运行过程中异常终止或崩溃时会发生 core dump，但还没说到什么具体的情景程序会发生异常终止或崩溃，例如我们使用 kill -9 命令杀死一个进程会发生 core dump 吗？实验证明是不能的，那么什么情况会产生呢？

       Linux 中信号是一种异步事件处理的机制，每种信号对应有其默认的操作，你可以在 这里 查看 Linux 系统提供的信号以及默认处理。默认操作主要包括忽略该信号（Ingore）、暂停进程（Stop）、终止进程（Terminate）、终止并发生core dump（core）等。如果我们信号均是采用默认操作，那么，以下列出几种信号，它们在发生时会产生 core dump:

Signal	Action	Comment
SIGQUIT	Core	Quit from keyboard
SIGILL	Core	Illegal Instruction
SIGABRT	Core	Abort signal from abort
SIGSEGV	Core	Invalid memory reference
SIGTRAP	Core	Trace/breakpoint trap

       当然不仅限于上面的几种信号。

       这就是为什么我们使用 Ctrl+z 来挂起一个进程或者 Ctrl+C 结束一个进程均不会产生 core dump，因为前者会向进程发出 SIGTSTP 信号，该信号的默认操作为暂停进程（Stop Process）；后者会向进程发出SIGINT 信号，该信号默认操作为终止进程（Terminate Process）。同样上面提到的 kill -9 命令会发出 SIGKILL 命令，该命令默认为终止进程。

      而如果我们使用 Ctrl+\ 来终止一个进程，会向进程发出 SIGQUIT 信号，默认是会产生 core dump 的。还有其它情景会产生 core dump， 如：程序调用 abort() 函数、访存错误、非法指令等等。

下面举两个例子来说明：

• 终端下比较 Ctrl+C 和 Ctrl+\：

  guohailin@guohailin:~$ sleep 10        #使用sleep命令休眠 10 s
  ^C                           #使用 Ctrl+C 终止该程序,不会产生 core dump
  guohailin@guohailin:~$ sleep 10
  ^\Quit (core dumped)                #使用 Ctrl+\ 退出程序, 会产生 core dump
  guohailin@guohailin:~$ ls         #多出下面一个 core 文件
  -rw-------  1 guohailin guohailin 335872 10月 22 11:31 sleep.core.21990
  

• 小程序产生 core dump

  #include <stdio.h>
  
  int main()
  {
      int *null_ptr = NULL;
      *null_ptr = 10;            //对空指针指向的内存区域写,会发生段错误
      return 0;
  }
  

  #编译执行
  guohailin@guohailin:~$ ./a.out
  Segmentation fault (core dumped)
  guohailin@guohailin:~$ ls      #多出下面一个 core 文件
  -rw-------  1 guohailin guohailin 200704 10月 22 11:35 a.out.core.22070    
  

4. Linux 下打开 Core Dump

     我使用的 Linux 发行版是 Ubuntu 13.04，设置生成 core dump 文件的方法如下：

• 打开 core dump 功能

  • 在终端中输入命令 ulimit -c ，输出的结果为 0，说明默认是关闭 core dump 的，即当程序异常终止时，也不会生成 core dump 文件。
  • 我们可以使用命令 ulimit -c unlimited 来开启 core dump 功能，并且不限制 core dump 文件的大小； 如果需要限制文件的大小，将 unlimited 改成你想生成 core 文件最大的大小，注意单位为 blocks（KB）。
  • 用上面命令只会对当前的终端环境有效，如果想需要永久生效，可以修改文件 /etc/security/limits.conf文件，关于此文件的设置参看 这里 。增加一行:

  # /etc/security/limits.conf
  #
  #Each line describes a limit for a user in the form:
  #
  #<domain>   <type>   <item>   <value>
      *          soft     core   unlimited
  

• 修改 core 文件保存的路径

  • 默认生成的 core 文件保存在可执行文件所在的目录下，文件名就为 core。
  • 通过修改 /proc/sys/kernel/core_uses_pid 文件可以让生成 core 文件名是否自动加上 pid 号。
    例如 echo 1 > /proc/sys/kernel/core_uses_pid ，生成的 core 文件名将会变成 core.pid，其中 pid 表示该进程的 PID。
  • 还可以通过修改 /proc/sys/kernel/core_pattern 来控制生成 core 文件保存的位置以及文件名格式。
    例如可以用 echo "/tmp/corefile-%e-%p-%t" > /proc/sys/kernel/core_pattern 设置生成的 core 文件保存在 “/tmp/corefile” 目录下，文件名格式为 “core-命令名-pid-时间戳”。这里 有更多详细的说明！

5. 使用 gdb 调试 Core 文件

产生了 core 文件，我们该如何使用该 Core 文件进行调试呢？Linux 中可以使用 GDB 来调试 core 文件，步骤如下：

• 首先，使用 gcc 编译源文件，加上 -g 以增加调试信息；
• 按照上面打开 core dump 以使程序异常终止时能生成 core 文件；
• 运行程序，当core dump 之后，使用命令 gdb program core 来查看 core 文件，其中 program 为可执行程序名，core 为生成的 core 文件名。

下面用一个简单的例子来说明：

#include <stdio.h>
int func(int *p)
{
    int y = *p;
    return y;
}
int main()
{
    int *p = NULL;
    return func(p);
}

编译加上调试信息, 运行之后core dump, 使用 gdb 查看 core 文件.

guohailin@guohailin:~$ gcc core_demo.c -o core_demo -g
guohailin@guohailin:~$ ./core_demo 
Segmentation fault (core dumped)

guohailin@guohailin:~$ gdb core_demo core_demo.core.24816
...
Core was generated by './core_demo'.
Program terminated with signal 11, Segmentation fault.
#0  0x080483cd in func (p=0x0) at core_demo.c:5
5       int y = *p;
(gdb)  where
#0  0x080483cd in func (p=0x0) at core_demo.c:5
#1  0x080483ef in main () at core_demo.c:12
(gdb) info frame
Stack level 0, frame at 0xffd590a4:
 eip = 0x80483cd in func (core_demo.c:5); saved eip 0x80483ef
 called by frame at 0xffd590c0
 source language c.
 Arglist at 0xffd5909c, args: p=0x0
 Locals at 0xffd5909c, Previous frame's sp is 0xffd590a4
 Saved registers:
  ebp at 0xffd5909c, eip at 0xffd590a0
(gdb) 

从上面可以看出,我们可以还原 core_demo 执行时的场景,并使用 where 可以查看当前程序调用函数栈帧, 还可以使用 gdb 中的命令查看寄存器,变量等信息.

PS:(补充的内容)System Dump和Core Dump的区别

       许多没有做过UNIX系统级软件开发的人士，可能只听说过Dump，而并不知道系统Dump和Core Dump的区别，甚至混为一谈。

0)概 论

        进程Core Dump的时候，操作系统会将进程异常终止掉并释放其占用的资源，不可能对系统本身的运行造成危害。这是与系统DUMP根本区别的一点：

        A. 系统DUMP产生时，一定伴随着系统崩溃和停机

         B. 进程Core Dump时，只会造成相应的进程被终止，系统本身不可能崩溃。当然如果此进程与其他进程有关联，其他进程也会受到影响，至于后果是什么，就看相关进程对这种异常情况（与自己相关的进程突然终止）的处理机制是什么了，没有一概的定论。

        进程Core Dump产生的技术原因，基本等同于系统DUMP，就是说从程序原理上来说是基本一致的。

1)系统Dump（System Dump）

所有开放式操作系统，都存在系统DUMP问题。

产生原因：

      由于系统关键/核心进程，产生严重的无法恢复的错误，为了避免系统相关资源受到更大损害，操作系统都会强行停止运行，并将当前内存中的各种结构,核心进程出错位置及其代码状态，保存下来，以便以后分析。最常见的原因是指令走飞，或者缓冲区溢出，或者内存访问越界。走飞就是说代码流有问题，导致执行到某一步指令混乱，跳转到一些不属于它的指令位置去执行一些莫名其妙的东西（没人知道那些地方本来是代码还是数据，而且是不是正确的代码开始位置），或者调用到不属于此进程的内存空间。写过C程序及汇编程序的人士，对这些现象应当是很清楚的。

系统DUMP生成过程的特点：

        在生成DUMP过程中，为了避免过多的操作结构，导致问题所在位置正好也在生成DUMP过程所涉及的资源中，造成DUMP不能正常生成，操作系统都用尽量简单的代码来完成，所以避开了一切复杂的管理结构，如文件系统）LVM等等，所以这就是为什么几乎所有开放系统，都要求DUMP设备空间是物理连续的——不用定位一个个数据块，从DUMP设备开头一直写直到完成，这个过程可以只用BIOS级别的操作就可以。这也是为什么在企业级UNIX普遍使用LVM的现状下，DUMP设备只可能是裸设备而不可能是文件系统文件，而且[b]只[/b]用作DUMP的设备，做 LVM镜像是无用的——系统此时根本没有LVM操作，它不会管什么镜像不镜像，就用第一份连续写下去。

所以UNIX系统也不例外，它会将DUMP写到一个裸设或磁带设备。在重启的时候，如果设置的DUMP转存目录（文件系统中的目录）有足够空间，它将会转存成一个文件系统文件，缺省情况下，[b]对于AIX来说是/var/adm/ras/下的vmcore*这样的文件，对于HPUX来说是 /var/adm/crash下的目录及文件。[/b]

当然，也可以选择将其转存到磁带设备。

会造成系统DUMP的原因主要是：

系统补丁级别不一致或缺少）系统内核扩展有BUG（例如Oracle就会安装系统内核扩展））驱动程序有 BUG（因为设备驱动程序一般是工作在内核级别的），等等。所以一旦经常发生类似的系统DUMP，可以考虑将系统补丁包打到最新并一致化）升级微码）升级设备驱动程序（包括FC多路冗余软件））升级安装了内核扩展的软件的补丁包等等。

2)进程Core Dump

       进程Core Dump产生的技术原因，基本等同于系统DUMP，就是说从程序原理上来说是基本一致的。

但进程是运行在低一级的优先级上（此优先级不同于系统中对进程定义的优先级，而是指CPU代码指令的优先级），被操作系统所控制，所以操作系统可以在一个进程出问题时，不影响其他进程的情况下，中止此进程的运行，并将相关环境保存下来，这就是core dump文件，可供分析。

        如果进程是用高级语言编写并编译的，且用户有源程序，那么可以通过在编译时带上诊断用符号表（所有高级语言编译程序都有这种功能），通过系统提供的分析工具，加上core文件，能够分析到哪一个源程序语句造成的问题，进而比较容易地修正问题，当然，要做到这样，除非一开始就带上了符号表进行编译，否则只能重新编译程序，并重新运行程序，重现错误，才能显示出源程序出错位置。

       如果用户没有源程序，那么只能分析到汇编指令的级别，难于查找问题所在并作出修正，所以这种情况下就不必多费心了，找到出问题的地方也没有办法。

        进程Core Dump的时候，操作系统会将进程异常终止掉并释放其占用的资源，不可能对系统本身的运行造成危害。这是与系统DUMP根本区别的一点，系统DUMP产生时，一定伴随着系统崩溃和停机，进程Core Dump时，只会造成相应的进程被终止，系统本身不可能崩溃。当然如果此进程与其他进程有关联，其他进程也会受到影响，至于后果是什么，就看相关进程对这种异常情况（与自己相关的进程突然终止）的处理机制是什么了，没有一概的定论。

      

---