Penguin
Blame: CommonProgrammingBugs
EditPageHistoryDiffInfoLikePages
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