Differences between version 10 and predecessor to the previous major change of CommonProgrammingBugs.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 10 | Last edited on Tuesday, November 9, 2004 2:40:40 am | by AristotlePagaltzis | Revert |
| Older page: | version 8 | Last edited on Thursday, February 5, 2004 3:00:13 pm | by JohnMcPherson | Revert |
@@ -1,29 +1,33 @@
-!!!My program causes a "[Segmentation Fault|SIGSEGV]"
in malloc(3) or new
-It's common for a program to cause a "Segmentation Fault" in new or malloc(3) if you have previously corrupted memory by using a pointer incorrectly.
+!!! My program causes a SegmentationFault
in malloc(3) or <tt>
new</tt>
-To diagnose this problem, compile everything with __-g__ (and probably [-Wall] as well) and link it all with electric fence (__
-lefence__).
+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:
-eg:
- [
gcc|gcc(1)]
-g [
-Wall]
broken.cc -o broken.o
- gcc -lefence broken.o -o broken
+<pre>
+__
gcc -g -Wall broken.cc -o broken.o__
+__
gcc -lefence broken.o -o broken__
+</pre>
-Check your ulimit(1) is not set to 0 (as
is the default on most recent distros).
-
ulimit -c unlimited
-This allows
your program to dump core.
+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:
-then run your program
- ./broken
- Segmentation Fault (core dumped)
-If you don't get the "(core dumped)" bit, then your ulimit is wrong, or you don't have write access to the current working directory, or the disk is full etc.
+<pre>
+__
./broken__
+Segmentation Fault (core dumped)
+</pre>
-Now that you have the program and the core file, use it to figure out where your program cored
- gdb ./broken ./core
-gdb will mutter on about stuff, if it says "(no symbols)" then you didn't compile with -g above.
-Then at the (gdb) prompt type "bt full"
- (gdb) bt full
-bt full 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.
+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
-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
()'d).
+<pre>
+__gdb
./broken ./core__
+
''lots
of chatter...''
+
(gdb
) __bt full__
+</pre>
-----
-See our
DeBugging page
for more details.
+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.
+
+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).
+
+See DeBugging for more details.
+
+!!! <tt>ld: ''name'': hidden symbol `__dso_handle' in foo.o is referenced by DSO</tt>
+
+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>
