Dealing with segmentation faults

heartless

Hi everyone,
I'd like to know how to prompt gdb to show me where segmentation fault in an application occurs and why. Any ideas?

chroot

Segfaults happen when your program tries to write to memory that doesn't belong to it. Common causes are:

1) Using uninitialized pointers.
2) Using uninitialized variables for pointer arithmentic (array indexing).
3) Letting a counter go beyond the boundaries of an array.

You should be able to use gdb to step through your code until you find the offending line.

- Warren

heartless

Yepp, that's what wikipedia says. However do you have any ideas how to find specific line or lines that cause segmentation fault in an application. I tried gdb for "normal" aps, and everything works perfectly, but I can't debug any applications with segmentation faults.

For example:
adrian@ubuntu:~/files/asm$ gdb env_show --quiet
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r
Starting program: /home/adrian/files/asm/env_show

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
You can't do that without a process to debug.
(gdb) info registers
The program has no registers now.
(gdb) bt
No stack.
(gdb)

and so on, I'm not very experienced with gdb,
--Thanks,

chroot

Rather than just running your program, put a breakpoint in and step through it line by line.

- Warren

chroot

Also, I presume that you compiled your program with gcc -g to include debugging information in the executable.

- Warren

nmtim

Or run gdb on the core dump. Never done it myself, but the core file should have the program state at the time of the segfault.