Write a sample program that generates a segmentation fault
In Ubuntu, core dumps are not generated by default. If you want the system to generate core dump, you need to enter the following command:
ulimit -c unlimited
In the above command, ulimit is to limit the usage of some user resources, including max user processes, the upper limit of open files, the upper limit of virtual memory, etc., and ulimit -c is to set the size of the core, unlimited means no upper limit, if you want To limit the size of the core, you can change unlimited to other numbers.
Next I wrote a test file that will cause a segmentation fault when executed:
/* myprogram.c */
int main() {
int *i;
*i = 1; // Assign before malloc
return 0;
}
Add -g debug option when compiling, and then execute:
gcc -g myprogram.c -o myprogram
./myprogram
Segmentation fault (core dumped)
At this time, there should be a file named core left in the current directory, see Method 1. If the file is not found, it means that the Linux version is relatively new, so you may not use this method, but use coredumpctl to manage core dumps, see Method 2.
Method 1
At this time, we want to find out where the program is wrong, so open gdb and enter the program name and core file name:
gdb myprogram core
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 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".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from myprogram...
[New LWP 3355]
Core was generated by `./myprogram'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000056139bf2f135 in main () at myprogram.c:4
4 *i = 1;
(gdb) q
Method 2
Install systemd-coredumpctl:
sudo apt install systemd-coredump
Then use coredumpctl to list the core dump records of myprogram:
TIME PID UID GID SIG COREFILE EXE SIZE
Sun 2022-10-02 19:52:44 CST 61547 1000 1000 SIGSEGV present /home/lin/Desktop/test/c/myprogram 18.1K
Then tell gdb to open the core dump with coredumpctl debug myprogram:
coredumpctl debug myprogram
PID: 61547 (myprogram)
UID: 1000 (lin)
GID: 1000 (lin)
Signal: 11 (SEGV)
Timestamp: Sun 2022-10-02 19:52:44 CST (1min 0s ago)
Command Line: ./myprogram
Executable: /home/lin/Desktop/test/c/myprogram
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-f9eab066-b8f1-4ae9-8e21-14c78f25dbe0.scope
Unit: user@1000.service
User Unit: vte-spawn-f9eab066-b8f1-4ae9-8e21-14c78f25dbe0.scope
Slice: user-1000.slice
Owner UID: 1000 (lin)
Boot ID: cbadc919c16149c8ae41b0a2ff2a94d4
Machine ID: bd90775ca2c24d75929026d99304a7c2
Hostname: Aspire7
Storage: /var/lib/systemd/coredump/core.myprogram.1000.cbadc919c16149c8ae41b0a2ff2a94d4.61547.1664711564000000.zst (present)
Disk Size: 18.1K
Message: Process 61547 (myprogram) of user 1000 dumped core.
Found module /home/lin/Desktop/test/c/myprogram with build-id: 95d32ba05adbce1c07d8f4a8c4eff5acf5a96cf8
Found module linux-vdso.so.1 with build-id: 88536f03982667a41f2be85c4e61e7e8307e2700
Found module ld-linux-x86-64.so.2 with build-id: 61ef896a699bb1c2e4e231642b2e1688b2f1a61e
Found module libc.so.6 with build-id: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d
Stack trace of thread 61547:
#0 0x000055983cee5135 n/a (/home/lin/Desktop/test/c/myprogram + 0x1135)
#1 0x00007fc884842d90 __libc_start_call_main (libc.so.6 + 0x29d90)
#2 0x00007fc884842e40 __libc_start_main_impl (libc.so.6 + 0x29e40)
#3 0x000055983cee5065 n/a (/home/lin/Desktop/test/c/myprogram + 0x1065)
GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
Copyright (C) 2022 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".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/lin/Desktop/test/c/myprogram...
[New LWP 61547]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./myprogram'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055983cee5135 in main () at myprogram.c:4
4 *i = 1;
(gdb) q
Use the bt Instruction for Back Trace
In the previous example, gdb successfully helped me find the error on line 4 of main() in myprogram.c.
However, if the program is complex and generates many function stacks, we may want to trace the calling order of every function stack. We can use bt (back trace) to find a series of function calls stack by stack, such as the following example:
/* myprogram.c */
void func() {
int *a;
*a = 1;
}
int main() {
func();
return 0;
}
The error is in func(), use bt in gdb to see:
Open core dump by gdb or coredumpctl.
. . .
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055ab058f0135 in func () at myprogram.c:4
(gdb) bt
#0 0x000055ab058f0135 in func () at myprogram.c:4
#1 0x000055ab058f0150 in main () at myprogram.c:8
You can see that gdb traces back to the call to func(), which is line 8 of main.c.
Top comments (1)
That's highly OS-dependent. See the answers to this question.