Segmentation fault in mallopt/malloc call

Discussion in 'C Programming' started by Alexandre, Feb 18, 2005.

  1. Alexandre

    Alexandre Guest

    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
     
    Alexandre, Feb 18, 2005
    #1
    1. Advertising

  2. 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
     
    Ulrich Eckhardt, Feb 18, 2005
    #2
    1. Advertising

  3. 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.
     
    Martin Ambuhl, Feb 18, 2005
    #3
  4. Alexandre

    Eric Sosman Guest

    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.

    --
     
    Eric Sosman, Feb 18, 2005
    #4
  5. Alexandre

    Alexandre Guest

    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, Feb 18, 2005
    #5
  6. Alexandre

    Alexandre Guest

    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
     
    Alexandre, Feb 18, 2005
    #6
  7. 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, Feb 20, 2005
    #7
  8. On Fri, 18 Feb 2005 -0500, Eric Sosman <> 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?
     
    RoSsIaCrIiLoIA, Mar 6, 2005
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bin Lu

    malloc segmentation fault

    Bin Lu, Oct 3, 2003, in forum: C Programming
    Replies:
    9
    Views:
    7,586
    Mark McIntyre
    Oct 23, 2003
  2. Dawn Minnis

    Malloc returning segmentation fault

    Dawn Minnis, Mar 15, 2005, in forum: C Programming
    Replies:
    2
    Views:
    473
  3. Zheng Da
    Replies:
    3
    Views:
    11,663
  4. I_have_nothing
    Replies:
    6
    Views:
    847
    I_have_nothing
    Jun 15, 2005
  5. S S
    Replies:
    2
    Views:
    505
    Ian Collins
    May 23, 2008
Loading...

Share This Page