Segmentation fault in mallopt/malloc call

[Alexandre]

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

[Martin Ambuhl]

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

This is almost 100% guaranteed to be the result of your program
corrupting your memory space. We can't guess where in your unshown code
this occurs.

[Ulrich Eckhardt]

Alexandre wrote:

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 [...] any idea why ?

Your whole process has access to the very memory that malloc uses for
internal housekeeping. Typical reason for this behaviour is buffer
overflows or buffer underflows, or some other random data corruption. Try
using a memory debugger (e.g. electric fence, valgrind). It's probably not
a bug in malloc(), those routines are usually well-tested.

Uli

[Eric Sosman]

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

[Alexandre]

Ulrich Eckhardt wrote:

Your whole process has access to the very memory that malloc uses for
internal housekeeping. Typical reason for this behaviour is buffer
overflows or buffer underflows, or some other random data corruption. Try
using a memory debugger (e.g. electric fence, valgrind). It's probably not
a bug in malloc(), those routines are usually well-tested.

danke für "electric fence"! das ist wunderbar! (ooops my german is a
little bit far... didn't speak it for ... zu viel zeit! (nearly 14 yrs))

ok, now I have a better idea for my problem! I will put the code in the
answear for Martin.

Alex, lothringisch im Paris.

[Alexandre]

Martin Ambuhl wrote:

This is almost 100% guaranteed to be the result of your program
corrupting your memory space. We can't guess where in your unshown code
this occurs.

thanks for your answear, but my aim was to know "how is it possible?",
and now with electric fence, I saw another place for my mistake and
modify my code and it works...
The code was too big to send...

Alexandre

[RoSsIaCrIiLoIA]

On Fri, 18 Feb 2005 18:10:53 -0500, Eric Sosman wrote:

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.

so where is the problem that you see and I not?
Can you please show me some code *where* malloc_debug() or malloc_m()
has some problems?
The only problem that I see for these functions is a "degenerate case"
like:

while(1)
{unsigned *h;
h=malloc_m(9 * sizeof *h);
if(fun(h)==1) break;
free_m(h); h=0;
verifica_all_m( );
}
free_m(h);

[RoSsIaCrIiLoIA]

On Fri, 18 Feb 2005 -0500, Eric Sosman <er*********@su n.com> wrote:
The way seems very well suited for numeric functions that write
arrays. If a function write a char out the array the program detect
(99%) this and point where there is the error. Today it has found an
error of that kind.
For generic function that write arrays it could not work well because
it is possible to write out of bounds but not in the boundary of
array.I'm in the kill filter?