Segmentation fault in mallopt/malloc call

A

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
 
U

Ulrich Eckhardt

Alexandre said:
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
 
M

Martin Ambuhl

Alexandre said:
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.
 
E

Eric Sosman

Alexandre said:
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.
 
A

Alexandre

Ulrich said:
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.
 
A

Alexandre

Martin said:
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
 
R

RoSsIaCrIiLoIA

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

RoSsIaCrIiLoIA

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?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top