GDB, core, and segment errors

To see if the system allows core files to be generated

• #ulimit-A
• Core file size (blocks,-c) 0

Core file size limit is 0 and core file cannot be generated

Use the following command to cancel the restriction so that the system can generate a core file

Ulimit-c Unlimited

The typical Linux operating system default core file size is 0 and needs to be set manually.

The debug core file core file is a binary file that requires the appropriate tools to parse the memory image when the program crashes. To view the core file with GDB:
Below we can take the core dump in case of an error caused by a runtime signal.
After core dump occurs, use GDB to view the contents of the core file to locate the row in the file that raised the core dump.
GDB [exec file] [core file]
Such as:
GdB./test Test.core
After entering GDB, use the BT command to view the backtrace to check where the program is running to locate the file-and-line of core dump.

Segment Error

In short, creating a segment error is accessing the wrong memory segment, usually because you don't have permissions, or there is no physical memory at all, especially if you have access to the 0 address.

The following types of practices in programming tend to lead to segment errors, which are basically caused by using pointers incorrectly

1) access to the system data area, especially to the system-protected memory address write data
The most common is to give a pointer to a 0 address
2) memory out of bounds (array out of bounds, variable type inconsistent, etc.) access to areas of memory that do not belong to you

Here are a few of the debugging methods for the following program, which has a segment error:

Dummy_function (voidchar0x00; 0x00 ;} int Main (void) {dummy_function (); return 0 ;}

The bug in the above code should be clear as a skilled C + + programmer, because it attempts to manipulate an area of memory where the address is 0, which is usually an inaccessible area, and of course it will go wrong. We try to compile and run it:
[Email protected] test $./a.out
Segment Error
As expected, it went wrong and exited.
1. Use GDB to step through a segment error:
This method is well known and widely used by the public, first we need an executable program with debugging information, so we add "-g-rdynamic" parameters to compile, and then debug with GDB to run the newly compiled program, the following steps:
[Email protected] test $ gcc-g-rdynamic D.C
[Email protected] 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.
Type "Show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "Show warranty" for details.
This GDB is 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 doesn't seem like we're going to need to debug. The 4th line of the D.C file is actually so simple.
From here we also find that the process is ended by receiving a SIGSEGV signal. With further documentation (man 7 signal), we know that the SIGSEGV default handler action is to print "segment error" error message and produce a core file, thus we have another method two.
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 contain ing 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 is found in signal (7).
The above data is excerpted from man page (man 5 core). Oddly enough, I didn't find the core file on my system. Later, recalled in order to reduce the system on the number of pull rubbish files (I am a bit neat, this is one of the reasons I like Gentoo), the core file is forbidden to build, see the following is true, the size of the system's core file is limited to 512K size, and then try:
[Email protected] test $ ulimit-c
0
[Email protected] test $ ulimit-c 1000
[Email protected] test $ ulimit-c
1000
[Email protected] test $./a.out
Segment error (Core dumped)
[Email protected] 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, debug with GDB to see it:
[Email protected] 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.
Type "Show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "Show warranty" for details.
This GDB is 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 is generated by './a.out '.
Program terminated with signal one, segmentation fault.
#0 0x08048524 in Dummy_function () at D.c:4
4 *ptr = 0x00;
Wow, good calendar harm, or a step on the location of the wrong location, admire the Linux/unix system of this kind of design.
Then consider, before using the Windows system of IE, sometimes open some Web pages, there will be "runtime error", this time if it happens to your machine is also installed on the Windows compiler, he will pop up a dialog box, ask you whether to debug, if you choose Yes, The compiler will be opened and put into the debug state to start debugging.
How do you do this under Linux? My brain was spinning so fast that, having it call GDB in SIGSEGV's handler, the third method was born:
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/cmdline", 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] = ' + ';
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 results of the compilation run as follows:
[Email protected] Test $ gcc-g-rdynamic F.C
[Email protected] 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.
Type "Show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "Show warranty" for details.
This GDB is 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
What do you think? Isn't it still cool?
The above methods are in the system on the premise of GDB, if not? In fact, GLIBC provides us with this kind of function to dump the contents of the cluster, see/usr/include/execinfo.h (These functions do not provide a man page, no wonder we can't find), you can also learn through the GNU manual.
4. Analysis using BackTrace and Objdump:
The rewritten 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 results of the compilation run are as follows:
[Email protected] Test $ gcc-g-rdynamic g.c
[Email protected] test $./a.out
Obtained 5 stack frames.
./a.out (dump+0x19) [0X80486C2]
[0xffffe420]
./a.out (MAIN+0X35) [0x804876f]
/lib/libc.so.6 (__libc_start_main+0xe6) [0xb7e02866]
./a.out [0x8048601]
This time you may be a little disappointed, do not seem to be able to give enough information to mark the error, not urgent, first see what can be analyzed, with the Objdump disassembly program, find the address 0x804876f corresponding code location:
[Email protected] test $ objdump-d a.out

8048765:e8-FE FF FF call 804856c <[email protected]>
804876A:E8 FF FF call 8048694 <dummy_function>
804876f:b8 xx xx $0x0,%eax
8048774:c9 leave
We still found out in which function (dummy_function) error, the information is not very complete, but there is always better than nothing!