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

[Michael Mair]

You probably have passed a pointer to free() which did not
contain the address of allocated memory.
Depending on your experience with debugging, there
are many sophisticated ways to find the culprit but if you
are not familiar, you can just find the faulty code by
1. creating a backup copy of your source
2. throwing everything out which goes before the malloc()
call (uncommenting, "#if 0"ing ...)
3. Now it will run (otherwise you can post a minimal example
along the lines of
#include <stdlib.h>
int main (void)
{
malloc(15); /*segfault*/
....
return 0;
}
in which case gcc is hopelessly broken)
4. Now re"insert" the left-out code from the beginning
until it segfaults.
5. Narrow it down, repair it, try the full version.
6. Either you are done or you continue at 4.

Cheers
Michael

--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Alexandre]

Michael Mair wrote:
> You probably have passed a pointer to free() which did not
> contain the address of allocated memory.
> Depending on your experience with debugging, there
> are many sophisticated ways to find the culprit but if you
> are not familiar, you can just find the faulty code by
> 1. creating a backup copy of your source
> 2. throwing everything out which goes before the malloc()
> call (uncommenting, "#if 0"ing ...)
> 3. Now it will run (otherwise you can post a minimal example
> along the lines of
> #include <stdlib.h>
> int main (void)
> {
> malloc(15); /*segfault*/
> ....
> return 0;
> }
> in which case gcc is hopelessly broken)
> 4. Now re"insert" the left-out code from the beginning
> until it segfaults.
> 5. Narrow it down, repair it, try the full version.
> 6. Either you are done or you continue at 4.

thank you for your help
on c.l.c someone counsel me to use electric-fence, which helps me a lot
to find my mistake.

Alexandre

[Paul Pluzhnikov]

Alexandre <a.hocque...@oreka.com> writes:

> this time, it's not my code who "segment fault" but it's in the call of
> malloc/mallopt

Any crash in malloc/realloc/free indicates (with very high
probability) that you have corrupted heap.

Some common ways to corrupt heap are: free non-malloc()ed
(e.g. global or stack) memory, free() something already free()d,
write past the end of malloc()ed buffer, etc.

> Program received signal SIGSEGV, Segmentation fault.
> 0x40094c97 in mallopt () from /lib/libc.so.6

Since you are on Linux, *the* tool to use is valgrind. It will
point you right at the error. Use it often, it will save you a lot
of trouble.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[Guy Harrison]

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?"

Code?

> 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

The only time I've known malloc/free to be buggy is when I've written them.

malloc() is rarely buggy. free() has two problems...

(a) losing same pointer more than once.
(b) dynamic memory is always blamed for overruns.

> 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 ?

Code?