Differences between version 6 and predecessor to the previous major change of CommonProgrammingBugs.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 6 | Last edited on Tuesday, September 2, 2003 1:30:23 am | by AristotlePagaltzis | Revert |
| Older page: | version 3 | Last edited on Friday, June 13, 2003 9:07:49 pm | by JohnMcPherson | Revert |
@@ -1,11 +1,11 @@
!!!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.
-To diagnose this problem, compile everything with "
-g"
(and probably "
-Wall"
as well) and link it all with electric fence ("
-lefence"
).
+To diagnose this problem, compile everything with __
-g__
(and probably [
-Wall]
as well) and link it all with electric fence (__
-lefence__
).
eg:
- gcc -g -Wall broken.cc -o broken.o
+ [
gcc|gcc(1)]
-g [
-Wall]
broken.cc -o broken.o
gcc -lefence broken.o -o broken
Check your ulimit(1) is not set to 0 (as is the default on most recent distros).
ulimit -c unlimited
@@ -25,13 +25,13 @@
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).
Other neat tools for diagnosing memory errors are:
-* valgrind
+* [Valgrind]
* electric fence
-* mmgr
(works well with C++)
+* [MMGR]
(works well with C++)
* [mcheck] (part of libc6-dev)
* [MALLOC_CHECK_] environment variable
* [LD_DEBUG] environment variable
* printf(3)
-* catchsegv (prints the backtrace of a program that segfaults) - don't forget to compile with "
-g"
if you want file names and line numbers
-* <add a
neat tool
you know of here>
+* catchsegv (prints the backtrace of a program that segfaults) - don't forget to compile with __
-g__
if you want file names and line numbers
+* AddToMe: any other
neat tools
you know of?
