Alexandre wrote:
Hello,
Maybe it's a little OT, but the fact is that I don't necessarly want to
know "how to correct?", but "why it happens?"
I have a program who "segment fault" (ok, that's "normal"... ;-) but
this time, it's not my code who "segment fault" but it's in the call of
malloc/mallopt
I've got:
with gcc 2.95.4
Program received signal SIGSEGV, Segmentation fault.
0x40085219 in malloc () from /lib/libc.so.6
with gcc 3.3.5
Program received signal SIGSEGV, Segmentation fault.
0x40094c97 in mallopt () from /lib/libc.so.6
any idea why ?
thanks by advance,
Alexandre, who is going to ask too in glibc and gcc newsgroups
This is Question 7.19 in the comp.lang.c Frequently
Asked Questions (FAQ) list
http://www.eskimo.com/~scs/C-faq/top.html
The exact failure mechanisms vary from one malloc()
implementation to another, but two vulnerabilities are
quite common:
- Many malloc() implementations store some of their
bookkeeping information in a small amount of extra
space attached to each block of memory. If you
write outside the allocated area it is likely that
you will overwrite some of this "metadata," and the
next time malloc() or one of its companion functions
tries to use the scrambled data things will go awry.
- Many malloc() implementations try to keep the amount
of per-block information as small as possible, because
a program may create a very large number of blocks.
This means there is often not enough information stored
to allow malloc() and its friends to do much error
checking. `char *p = malloc(N); free(p); free(p);'
might very easily do something like introduce a loop
into what ought to be a straight-line linked list;
`char *p = "Hello"; char *q = realloc(p, 42);' could
scramble things quite thoroughly.
Some "debug malloc" packages try to guard against such
errors or at least make them easier to detect, but the cost
(in memory and in time) is often quite high, which is one
reason such programmer-friendly features are often absent
from "production" libraries.
--
Er*********@sun.com