Annotated edit history of
CommonProgrammingBugs version 11, including all changes.
View license author blame.
Rev |
Author |
# |
Line |
10 |
AristotlePagaltzis |
1 |
!!! My program causes a SegmentationFault in malloc(3) or <tt>new</tt> |
1 |
PerryLorier |
2 |
|
10 |
AristotlePagaltzis |
3 |
It's common for a program to cause a SegmentationFault in <tt>new</tt> or malloc(3) if you have previously corrupted memory by using a pointer incorrectly. To diagnose this problem, compile everything with __-g__ (and probably [-Wall] as well) and link it all with electric fence using <tt>-lefence</tt>, eg: |
1 |
PerryLorier |
4 |
|
10 |
AristotlePagaltzis |
5 |
<pre> |
|
|
6 |
__gcc -g -Wall broken.cc -o broken.o__ |
|
|
7 |
__gcc -lefence broken.o -o broken__ |
|
|
8 |
</pre> |
1 |
PerryLorier |
9 |
|
10 |
AristotlePagaltzis |
10 |
Check your ulimit(1) is not set to 0 (this is the default on most recent distros, use <tt>ulimit -c unlimited</tt> to allow your program to dump core), then run your program: |
1 |
PerryLorier |
11 |
|
10 |
AristotlePagaltzis |
12 |
<pre> |
|
|
13 |
__./broken__ |
|
|
14 |
Segmentation Fault (core dumped) |
|
|
15 |
</pre> |
1 |
PerryLorier |
16 |
|
10 |
AristotlePagaltzis |
17 |
If you don't get the <tt>(core dumped)</tt> bit, then your ulimit is wrong, or you don't have write access to the current working directory, or the disk is full etc. Now that you have the program and the core file, use it to figure out where your program cored |
1 |
PerryLorier |
18 |
|
10 |
AristotlePagaltzis |
19 |
<pre> |
|
|
20 |
__gdb ./broken ./core__ |
|
|
21 |
''lots of chatter...'' |
|
|
22 |
(gdb) __bt full__ |
|
|
23 |
</pre> |
9 |
JohnMcPherson |
24 |
|
10 |
AristotlePagaltzis |
25 |
If it says <tt>(no symbols)</tt> then you didn't compile with <tt>-g</tt> above. <tt>bt full</tt> will take the __b__ack__t__race of the core file and if you specify "full" it'll show you all the variables along the way. |
9 |
JohnMcPherson |
26 |
|
10 |
AristotlePagaltzis |
27 |
The first line should be the place where your bug occured. If you look at this line you'll probably find you're doing something silly (like addressing past the end of an array, or using a pointer that has been free(3)d). |
9 |
JohnMcPherson |
28 |
|
10 |
AristotlePagaltzis |
29 |
See DeBugging for more details. |
1 |
PerryLorier |
30 |
|
10 |
AristotlePagaltzis |
31 |
!!! <tt>ld: ''name'': hidden symbol `__dso_handle' in foo.o is referenced by DSO</tt> |
|
|
32 |
|
|
|
33 |
You are linking against a shared library that was created incorrectly. With [GCC] 3.x this might happen if you create a SharedLibrary directly using <tt>ld -shared -o libfoo.so ...</tt>. Instead, use <tt>g++ -shared -Wl,-soname,libfoo.so.1 -o libfoo.so ...</tt> |
11 |
LawrenceDoliveiro |
34 |
|
|
|
35 |
---- |
|
|
36 |
CategoryProgrammingBugs |