What causes segmentations faults in malloc?

[Chris]

A general question here, what causes segmentation faults in malloc?
Shouldn't malloc always gracefully fail? Take a look at the gdb core
stack trace (from an HP-UX 11.11)

Program terminated with signal 11, Segmentation fault.

#0 0xc01961c8 in mallinfo+0x718 () from /usr/lib/libc.2
(gdb) where
#0 0xc01961c8 in mallinfo+0x718 () from /usr/lib/libc.2
#1 0xc0198690 in _sbrk+0x580 () from /usr/lib/libc.2
#2 0xc0196bb4 in _sigfillset+0x7a4 () from /usr/lib/libc.2
#3 0xc0194774 in _sscanf+0x54c () from /usr/lib/libc.2
#4 0xc0199944 in malloc+0x18c () from /usr/lib/libc.2

Has anybody seen this before? Obviously I'm doing something wrong, but
I'm not doing any free()ing.

Thanks in advance,

~Chris

 

[Joona I Palaste]

A general question here, what causes segmentation faults in malloc?
Shouldn't malloc always gracefully fail? Take a look at the gdb core
stack trace (from an HP-UX 11.11)

You may have caused undefined behaviour earlier, by accessing memory
that doesn't officially belong to your program. This may have muddled up
malloc's magical internal tables.
For a more specific answer, head off to gnu.gcc.help or
comp.unix.programmer.

 

[Ben Pfaff]

A general question here, what causes segmentation faults in malloc?

A segmentation fault in malloc() means that you wrote to memory
that you did not own. This might mean that you wrote to memory
before or after a block you allocated, that you wrote to a block
after you freed it, that you passed an invalid pointer (such as a
block already freed or a pointer in the middle of a block) to
free(), or one of a host of other possibilities.

Try using a memory debugger such as Electric Fence or valgrind.

 

[Eric Sosman]

A general question here, what causes segmentation faults in malloc?
Shouldn't malloc always gracefully fail? [...]

This is Question 7.19 in the comp.lang.c Frequently
Asked Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

 

[Jared Dykstra]

A segmentation fault in malloc() means that you wrote to memory
that you did not own. This might mean that you wrote to memory
before or after a block you allocated, that you wrote to a block
after you freed it, that you passed an invalid pointer (such as a
block already freed or a pointer in the middle of a block) to
free(), or one of a host of other possibilities.

Try using a memory debugger such as Electric Fence or valgrind.

Those are always fun. Typically this happens from free()-ing memory
you didn't own, or trying to free() previously deallocated memory. It
is a good habbit to set pointers back to NULL after freeing memory,
and using assert() calls to validate pointers before doing stuff with
them.

C++ builds in protection if you stick to using the new and delete
operators, and encapsulate it in an object; deleting an object twice
will not cause any ill side-effects.

Use the tools mentioned by Ben, and you'll save yourself tons of time.

 

[Ben Pfaff]

#include <string>

Please take a walk down to comp.lang.c++ if you're going to say
things like that.

 

[Kevin Goodsell]

Those are always fun. Typically this happens from free()-ing memory
you didn't own, or trying to free() previously deallocated memory. It
is a good habbit to set pointers back to NULL after freeing memory,
and using assert() calls to validate pointers before doing stuff with
them.

I disagree. This can lead people to incorrectly assume that a non-NULL
pointer which was previously made to point to dynamically allocated
memory is safe to use. After all, if the memory had been freed, the
pointer would be NULL, right? Well, no. You could have had more than one
pointer to that location, and it may have been freed through a different
pointer.

Assuming a non-NULL pointer can be dereferenced is very dangerous.
Setting freed pointers to NULL (as a general policy) is, in my opinion,
a half-assed attempt at solving a problem which can only truly be solved
by using good design and proper code organization.

C++ builds in protection if you stick to using the new and delete
operators, and encapsulate it in an object; deleting an object twice
will not cause any ill side-effects.

I consider undefined behavior to be an ill side-effect.

$ cat test.cpp
#include <string>

int main()
{
std::string *p = new std::string;
delete p;
delete p;

return 0;
}

$ g++ test.cpp

$ ./a
Segmentation fault (core dumped)

$

-Kevin

 

[Jared Dykstra]

I disagree. This can lead people to incorrectly assume that a non-NULL
pointer which was previously made to point to dynamically allocated
memory is safe to use. After all, if the memory had been freed, the
pointer would be NULL, right? Well, no. You could have had more than one
pointer to that location, and it may have been freed through a different
pointer.

Doing this isn't going to solve all of your problems and bring world
peace, but if you can quickly catch 25% of potential errors, I think
that is a valid reason for doing something.

To rehash the classic argument, if I see one white swan, I cannot
correctly assume all swans are white. You can never assume all
non-null pointers always reference valid allocated memory. If,
however, I kill every black swan I see, the probability of the a
random swan being white starts to go up. OK, maybe that last bit went
a little too far ;-)