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 7 17047
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
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
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
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.
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.
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: stephenma7 |
last post by:
Hi, everybody. I am new here.
I have encountered these many problems for the last couple of days. I
have Linux Fedora Core 3(Gnu G++ 3.4.2), Linux Fedora Core 2 (Gnu G++
3.3.3), Red Hat 9 (Gnu...
|
by: Alawna |
last post by:
Hi,
i was reading a chapter about c pointers in "c++builder complete
reference" and it is said there that malloc returns a pointer to the
start of the memory allocated but i see the prototype of...
|
by: Pegaso |
last post by:
Hi... I have created a utility library with VC++ 7.1 which is used by a VB 6
client. The library creates a secondary thread of execution in order to
listen for connections on a socket. The...
|
by: Stanley S |
last post by:
Hi,
I'm puzzled. Why does the following cause a seg fault? Notwithstanding
that I've already malloc() a certain space for "Hello".
I do understand that using a fixed length array will work...
|
by: neilcancer |
last post by:
i come from china,and i'm sorry that my english is very poor.
now i'm studing data structure and i met some problem about c language.
could you tell me what will happen after i use free()? i...
|
by: quiberon2 |
last post by:
Hi,
Sorry if it might be a stupid question but what should returns
malloc(0) ?
void *ptr = malloc(0);
I am running gcc 3.3.5 and a non-null address is returned.
( in the compiler that I am...
|
by: itsolution |
last post by:
Hi folks,
Could you shed some light on this issue?
my program is running on Freebsd as a daemon. When user sends a
request, it forks itself and lets its child process handles the
request....
|
by: mathieu.dutour |
last post by:
Dear all,
I am new to C and I have a problem with "segmentation fault" occurring
unexpectedly, i.e., not immediately after a programming error. I
presume
I allocated wrongly before, but I can't...
|
by: kiser89 |
last post by:
I'm having a problem with my array of structs and segmentation faults. I have this struct that represents one line of a source file:
struct threeTokens {
int lineNumber;
char* cmd;
char* param;...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |