By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,898 Members | 2,012 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,898 IT Pros & Developers. It's quick & easy.

What causes segmentations faults in malloc?

P: n/a
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
Nov 14 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Chris <go***************@spamgourmet.com> scribbled the following:
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.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Roses are red, violets are blue, I'm a schitzophrenic and so am I."
- Bob Wiley
Nov 14 '05 #2

P: n/a
go***************@spamgourmet.com (Chris) writes:
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.
--
"Given that computing power increases exponentially with time,
algorithms with exponential or better O-notations
are actually linear with a large constant."
--Mike Lee
Nov 14 '05 #3

P: n/a
Chris wrote:

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

--
Er*********@sun.com
Nov 14 '05 #4

P: n/a
Ben Pfaff <bl*@cs.stanford.edu> wrote in message news:<87************@pfaff.stanford.edu>...
go***************@spamgourmet.com (Chris) writes:
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.

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.

---
Jared Dykstra
http://www.bork.org/~jared
Nov 14 '05 #5

P: n/a
Jared Dykstra wrote:

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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Nov 14 '05 #6

P: n/a
Kevin Goodsell <us*********************@neverbox.com> writes:
#include <string>


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

P: n/a
Kevin Goodsell <us*********************@neverbox.com> wrote in message news:<WQ*****************@newsread2.news.pas.earth link.net>...
Jared Dykstra wrote:

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.


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 ;-)

---
Jared Dykstra
http://www.bork.org/~jared
Nov 14 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.