Core files and GDB debugging

This article provides a brief introduction to the core file and gdb Debug Core file method

Profile:

1. Core file

2. Configure the core program to generate files when it crashes

3. Can modify the core file name

4. The case where the core file is generated

5. GDB Debug Core file

a) gdb-c <xxx.core> [executable program]

b) gdb command: BACKTRACE/BT

c) gdb command: Up/down/frame

d) gdb command: Info locals

e) gdb command: Info args

f) gdb command: Print < variable name >/print *< variable name >

1. Core file

Linux/unix, the executable program crashes when the core file is generated. The core file is a memory image that you can use to debug the program to find out why the program crashed.

2. Configure the core program to generate files when it crashes

Linux/unix, through limit-a, you can see if the system generates a core file for a program crash. Where core file size refers to the size of the resulting core files. The following is a line of output limit-a output from the FreeBSD system, unlimited means no limit, if the unlimited is 1024, the resulting core file is 1024 blocks in size and 512 bytes per block. If 0, the core file is not produced.

Core file Size (512-blocks,-c) Unlimited

Core file Size (512-blocks,-c) 1024

Core file Size (512-blocks,-c) 0

With the limit command, you can change the settings. such as Ulimit-c Unlimited or limit-c 1024.

3. Can modify the core file name

The core file is generated in the working directory of the program, the system name is not the same as FreeBSD, the default name is the program name. Core, which can be modified. FreeBSD, through the man core can be known, through the SYSCTL can see the core file name rules and modify it. The following is the core file name consisting of the program name. Core.

[Email protected]:/# Sysctl-a | grep corefile

Kern.corefile:%n.core

Under FreeBSD view man core, you can know the rules that are available when the core file is named:

The name of the file is controlled via the SYSCTL (8) variable

Kern.corefile. The contents of this variable describes a filename to

Store the core image to. This filename can be absolute, or relative

(which'll resolve to the current working directory of the program gen-

Erating it).

The following format specifiers is used in the Kern.corefile sysctl

To insert additional information into the resulting core file name:

%H machine hostname.

%I An index starting at zero until the Sysctl debug.ncores

is reached. This can is useful for limiting the number

of Corefiles generated by a particular process.

%N process name.

%P processes PID.

%u process UID.

4. The case where the core file is generated

A fatal error occurs while the program is running, causing the program to crash, resulting in a core file. When the system captures signals such as SIGSEGV, the core file is produced.

With man signal, you can see what information will produce the core:

Num Name Default Action Description

1 SIGHUP Terminate process terminal line Hangup

2 SIGINT Terminate process interrupt Program

3 Sigquit Create core Image quit program

4 Sigill Create core image illegal instruction

5 SIGTRAP Create core image trace trap

6 SIGABRT Create Core Image Abort Program (formerly Sigiot)

7 SIGEMT Create core image emulate instruction executed

8 SIGFPE Create core Image floating-point exception

9 SIGKILL Terminate process Kill program

Sigbus Create core Image Bus error

SIGSEGV Create Core Image Segmentation violation

Sigsys Create core Image non-existent system call invoked

The most common cause of a program crash is SIGSEGV (illegal access to memory).

5. GDB Debug Core file

1) When the program is encoded, add the-G option to increase debug information.

2) Debug the core file with GDB to see the program running status.

Some common commands are listed below:

a) gdb-c <xxx.core> [executable program]

Run GDB and dispatch the core file. Here is the directory where my executable program is located:

[Email PROTECTED]:~/TEST/CORE_STATCK # ls

Core_stack Core_stack.core Core_stack.cpp

Core_stack.cpp source File

Core_stack executable program compiled by the source file

Core_stack.core Core_stack generated core file

After entering the command, GDB runs and outputs a lot of information, which is basically the information that loads the library. Finally, the information in the last stack is also output. At this point gdb is in the No. 0 stack state.

[Email protected]:~/test/core_statck # gdb-c Core_stack.core core_stack

GNU gdb 6.1.1 [FreeBSD]

Copyright 2004 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.

Type "Show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "Show warranty" for details.

This GDB is configured as "I386-marcel-freebsd" ...

Core is generated by ' core_stack '.

Program terminated with signal 6, aborted.

Reading symbols From/usr/lib/libc++.so.1...done.

Loaded symbols For/usr/lib/libc++.so.1

Reading symbols From/lib/libcxxrt.so.1...done.

Loaded symbols For/lib/libcxxrt.so.1

Reading symbols From/lib/libm.so.5...done.

Loaded symbols for/lib/libm.so.5

Reading symbols From/lib/libgcc_s.so.1...done.

Loaded symbols For/lib/libgcc_s.so.1

Reading symbols From/lib/libc.so.7...done.

Loaded symbols for/lib/libc.so.7

Reading symbols From/libexec/ld-elf.so.1...done.

Loaded symbols For/libexec/ld-elf.so.1

#0 0x2829a467 in Kill () from/lib/libc.so.7

(GDB)

b) gdb command: BACKTRACE/BT

The GDB command BT can output the information on the stack before the program crashes, mainly the call stack of the program.

(gdb) bt

#0  0x2829a467 in Kill () from/lib/libc.so.7

#1  0x2829a 3f7 in Raise () from/lib/libc.so.7

#2  0x28298b06 in Abort () from/lib/libc.so.7

#3  0x282797f 8 in __assert () from/lib/libc.so.7

#4  0x08049de0 in Mydump::p rint (THIS=0XBFBFECD8, x=4, Core=false) at Co Re_stack.cpp:13

#5  0x080491bd in Mydump::d etaildump (THIS=0XBFBFECD8, a=111, b=222) at core_stack.cpp:35

#6  0x08049166 in Mydump::d UMP (THIS=0XBFBFECD8, Level=0, a=111, b=222) at core_stack.cpp:30

#7   0x08049140 in Mydump::d UMP (THIS=0XBFBFECD8, Level=1, a=111, b=222) @ core_stack.cpp:28

#8  0x08049140 in My Dump::d UMP (THIS=0XBFBFECD8, level=2, a=111, b=222) at core_stack.cpp:28

#9  0x08049140 in Mydump::d UMP (this =0XBFBFECD8, Level=3, a=111, b=222) at core_stack.cpp:28

#10 0x0804928f in Main () at core_stack.cpp:46

As can be seen from the above output, the program's call situation, but also output the corresponding line number in the source file.

c) gdb command: Up/down/frame

Up: Make a previous stack

Down: Go to next stack

Frame N: Making nth Stack

These three commands are primarily the user switching the stack that GDB is currently in. When GDB handles the state of a stack, it can view the information in the stack with commands such as Info,print.

d) gdb command: Info locals

View local variables, a useful command. As you can see, there is a local variable Lev within the function, with a value of 2

(GDB) Info locals

Lev = 2

e) gdb command: Info args

View function parameters, a useful command. Below you can see that the parameters of the function are the this, the level, a, B, and their values.

(GDB) Info args

this = (Mydump *) 0XBFBFECD8

Level = 2

A = 111

b = 222

f) gdb command: Print < variable name >/print *< variable name >

A useful command is to view the value of a variable and the variable that the pointer refers to. Print prints the variables that are visible on the current stack, including local variables, function parameters, global variables, and so on. The following is an object that outputs this pointer, this object has a member variable m_n, with a value of 4

(gdb) Print *this

$6 = {m_n = 4}

Info locals, info args, print three commands together, it's basically easy to understand the current state of the program core and the reason for locating the core.

The above command, in most cases, can pinpoint the problem with the program core. However, for complex stack situations or data corruption in the stack, this is more likely to be detected. For more commands and usage, you need to look at the man gdb and GDB command help to understand.

This article is from the "Chhquan" blog, make sure to keep this source http://chhquan.blog.51cto.com/1346841/1711225

Core files and GDB debugging