Dealing with segmentation faults

  • Thread starter Thread starter heartless
  • Start date Start date
Click For Summary

Discussion Overview

The discussion centers around how to effectively use gdb to identify the source of segmentation faults in applications. Participants explore various methods and considerations for debugging, including the use of breakpoints and core dumps.

Discussion Character

  • Technical explanation
  • Debate/contested

Main Points Raised

  • One participant inquires about how to prompt gdb to show the location and cause of segmentation faults.
  • Another participant lists common causes of segmentation faults, such as using uninitialized pointers and exceeding array boundaries.
  • A participant shares their experience with gdb, noting difficulties in debugging applications that encounter segmentation faults, particularly when no debugging symbols are found.
  • One suggestion is made to set breakpoints and step through the code to identify issues.
  • Another participant emphasizes the importance of compiling the program with debugging information using the gcc -g option.
  • A further suggestion is made to analyze core dumps to investigate the program state at the time of the segmentation fault.

Areas of Agreement / Disagreement

Participants express varying levels of familiarity with gdb and its debugging capabilities, indicating that there is no consensus on the best approach to identify segmentation faults. Multiple strategies are proposed, but no single method is agreed upon as definitive.

Contextual Notes

Some participants mention the necessity of debugging symbols and the potential limitations of gdb when debugging certain applications. There is also uncertainty regarding the effectiveness of core dumps for debugging segmentation faults.

Who May Find This Useful

This discussion may be useful for software developers, particularly those working with C/C++ applications, who are seeking to troubleshoot segmentation faults using gdb.

heartless
Messages
220
Reaction score
2
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?
 
Technology news on Phys.org
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
 
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,
 
Rather than just running your program, put a breakpoint in and step through it line by line.

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

- Warren
 
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.
 

Similar threads

  • · Replies 9 ·
Replies
9
Views
2K
  • · Replies 3 ·
Replies
3
Views
2K
  • · Replies 3 ·
Replies
3
Views
2K
Replies
2
Views
2K
Replies
8
Views
14K
  • · Replies 7 ·
Replies
7
Views
5K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 2 ·
Replies
2
Views
857
  • · Replies 4 ·
Replies
4
Views
2K
  • · Replies 5 ·
Replies
5
Views
3K