Debugging of segment errors and bugs

 

When we write programs in C/C ++, most of the work of memory management needs to be done. In fact, memory management is a tedious task. No matter how clever and experienced you are, it is inevitable that you will make some small errors here. These errors are usually so simple and easy to eliminate. However, manual debugging is often inefficient and annoying, this article will talk about how to quickly locate these "segment errors" statements about memory access out-of-bounds errors.

The following describes several debugging methods for a program with a segment error:

1 dummy_function (void)

2 {

3 unsigned char * ptr = 0x00;

4 * ptr = 0x00;

5}

6

7 int main (void)

8 {

9 dummy_function ();

10

11 return 0;

12}

 

As a skilled C/C ++ programmer, the bug of the above Code should be very clear, because it tries to operate on the memory area with the address 0, this memory area is usually inaccessible, and of course there will be errors. Let's compile and run it:

Xiaosuo @ gentux test $./a. out

Segment Error

 

As expected, it went wrong and exited.

1. Use gdb to gradually find the segment error:

This method is also widely known and widely used. First, we need an executable program with debugging information. Therefore, we add the "-g-rdynamic" parameter to compile the program, use gdb to debug and run the newly compiled program. The specific steps are as follows:

Xiaosuo @ gentux test $ gcc-g-rdynamic d. c

Xiaosuo @ gentux test $ gdb./a. out

GNU gdb 6.5

Copyright (C) 2006 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 "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1 ".

 

(Gdb) r

Starting program:/home/xiaosuo/test/a. out

 

Program received signal SIGSEGV, Segmentation fault.

0x08048524 in dummy_function () at d. c: 4

4 * ptr = 0x00;

(Gdb)

 

Oh ?! It seems that we did not need to debug step by step to find the Error Path line 4th of the d. c file, which is actually so simple.

We also found that the process ended with the SIGSEGV signal. After further reading the document (man 7 signal), we know that the default handler action of SIGSEGV is to print the error message of "segment error" and generate a Core file, therefore, method 2 is generated.

2. Analyze the Core file:

What is a Core file?

The default action of certain signals is to cause a process to terminate and produce a core dump file, a disk file containing an image of the process's memory at the time of termination. A list of the signals which cause a process to dump core can be found in signal (7 ).

The above information is taken from man page (man 5 core ). But it's strange that the core file is not found on my system. Later, I recalled that in order to gradually reduce the number of pull files on the system (I am somewhat clean, which is one of the reasons I like Gentoo), and disabled the generation of core files, check that the following is true, limit the size of the system core file to kb, and try again:

Xiaosuo @ gentux test $ ulimit-c

0

Xiaosuo @ gentux test $ ulimit-c 1000

Xiaosuo @ gentux test $ ulimit-c

1000

Xiaosuo @ gentux test $./a. out

Segment error (core dumped)

Xiaosuo @ gentux test $ ls

A. out core d. c f. c g. c pango. c test_iconv.c test_regex.c

 

The core file is finally generated. Use gdb to debug it:

Xiaosuo @ gentux test $ gdb./a. out core

GNU gdb 6.5

Copyright (C) 2006 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 "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1 ".

 

 

Warning: Can't read pathname for load map: input/output error.

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

Core was generated by './a. out '.

Program terminated with signal 11, Segmentation fault.

#0 0x08048524 in dummy_function () at d. c: 4

4 * ptr = 0x00;

 

Wow, it's a good experience. I just got to the wrong location and admire the design of Linux/Unix systems.

Next, when I used Internet Explorer in windows, sometimes some web pages may encounter "runtime errors ", at this time, if a windows compiler is installed on your machine, a dialog box will pop up asking you if you want to debug it. If you choose yes, the compiler will be opened, and enter the debugging status to start debugging.

How can we achieve this in Linux? My brain is spinning at a high speed. Now, let it call gdb in the handler of SIGSEGV, so the third method is born again:

3. Start debugging when a segment error occurs:

# Include <stdio. h>

# Include <stdlib. h>

# Include <signal. h>

# Include <string. h>

 

Void dump (int signo)

{

Char buf [1024];

Char cmd [1024];

FILE * fh;

 

Snprintf (buf, sizeof (buf), "/proc/% d/define line", getpid ());

If (! (Fh = fopen (buf, "r ")))

Exit (0 );

If (! Fgets (buf, sizeof (buf), fh ))

Exit (0 );

Fclose (fh );

If (buf [strlen (buf)-1] = '\ n ')

Buf [strlen (buf)-1] = '\ 0 ';

Snprintf (cmd, sizeof (cmd), "gdb % s % d", buf, getpid ());

System (cmd );

 

Exit (0 );

}

 

Void

Dummy_function (void)

{

Unsigned char * ptr = 0x00;

* Ptr = 0x00;

}

 

Int

Main (void)

{

Signal (SIGSEGV, & dump );

Dummy_function ();

 

Return 0;

}

 

The compilation and running effect is as follows:

Xiaosuo @ gentux test $ gcc-g-rdynamic f. c

Xiaosuo @ gentux test $./a. out

GNU gdb 6.5

Copyright (C) 2006 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 "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1 ".

 

Attaching to program:/home/xiaosuo/test/a. out, process 9563

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

0xffffe410 in _ kernel_vsyscall ()

(Gdb) bt

#0 0xffffe410 in _ kernel_vsyscall ()

#1 0xb7ee4b53 in waitpid () from/lib/libc. so.6

#2 0xb7e925c9 in strtold_l () from/lib/libc. so.6

#3 0x08048830 in dump (signo = 11) at f. c: 22

#4 <signal handler called>

#5 0x0804884c in dummy_function () at f. c: 31

#6 0x08048886 in main () at f. c: 38

 

How is it? Is it still cool?

The above methods are implemented on the premise that gdb is available on the system. If not, what should I do? Actually, glibc provides us with such function clusters that can dump stack content. For details, see/usr/include/execinfo. h (no man page is provided for these functions, so we can't find them). You can also learn from the gnu manual.

4. Use backtrace and objdump for analysis:

The rewrite code is as follows:

# Include <execinfo. h>

# Include <stdio. h>

# Include <stdlib. h>

# Include <signal. h>

 

/* A dummy function to make the backtrace more interesting .*/

Void

Dummy_function (void)

{

Unsigned char * ptr = 0x00;

* Ptr = 0x00;

}

 

Void dump (int signo)

{

Void * array [10];

Size_t size;

Char ** strings;

Size_t I;

 

Size = backtrace (array, 10 );

Strings = backtrace_symbols (array, size );

 

Printf ("Obtained % zd stack frames. \ n", size );

 

For (I = 0; I <size; I ++)

Printf ("% s \ n", strings [I]);

 

Free (strings );

 

Exit (0 );

}

 

Int

Main (void)

{

Signal (SIGSEGV, & dump );

Dummy_function ();

 

Return 0;

}

 

The compilation and running results are as follows:

Xiaosuo @ gentux test $ gcc-g-rdynamic g. c

Xiaosuo @ gentux test $./a. out

Obtained 5 stack frames.

./A. out (dump + 0x19) [0x80486c2]

[0xffffe420]

./A. out (main + 0x35) [0x802136f]

/Lib/libc. so.6 (_ libc_start_main + 0xe6) [0xb7e02866]

./A. out [0x8048601]

 

This time you may be disappointed. It seems that you have not provided enough information to mark the error. Don't worry. First, let's take a look at what can be analyzed. Use the objdump disassembly program to find the code location corresponding to address 0x801166f:

Xiaosuo @ gentux test $ objdump-d a. out

 

 

8048765: e8 02 fe ff call 804856c <signal @ plt>

80100006a: e8 25 ff call 8048694 <dummy_function>

80100006f: b8 00 00 00 mov $0x0, % eax

8048774: c9 leave

 

We still found the function (dummy_function) in which the error occurred. The information is not complete, but it is always better!

Postscript:

This article provides several methods for analyzing "segment errors". Do not think this is the same as the four methods of "back" written by Mr. Kong Yiji, because each method has its own applicability and applicable environment, please use it as appropriate or follow the doctor's advice.

 

From: Free Gentux