SIGSEGV in malloc()

Discussion in 'C Programming' started by Joakim Hove, May 7, 2007.

  1. Joakim Hove

    Joakim Hove Guest

    Hello,

    in my application I have a typedefed struct:

    typedef struct {
    double d1;
    int i1;
    /* I have simplified the object here. */
    } data_ptr_type;


    I allocate storage for such object many times in my application, and
    at some point in time (repeatedly at the same spot, but seemingly
    random to me), the application fails with a SIGSEGV at:

    data_ptr_type * data = malloc(sizeof *data);

    To me it seems quite illogical that the malloc implementation should
    be able to die with a SIGSEGV(?) - either it should return a pointer
    to freshly allocated storage, or if that is not possible it should
    return NULL. Can this be a sign of a bug in the malloc()
    implementation - I know that sounds unlikely but??

    My system is:
    RedHat Enterprise Linux
    gcc-3.4.6
    64 bit computer, but comiled with -m32 switch.

    Any suggestions?

    Regards Joakim
     
    Joakim Hove, May 7, 2007
    #1
    1. Advertising

  2. Joakim Hove said:

    <snip>

    > I allocate storage for such object many times in my application, and
    > at some point in time (repeatedly at the same spot, but seemingly
    > random to me), the application fails with a SIGSEGV at:
    >
    > data_ptr_type * data = malloc(sizeof *data);
    >
    > To me it seems quite illogical that the malloc implementation should
    > be able to die with a SIGSEGV(?) -


    It's impossible to say for sure without seeing the code, but it's my
    guess that you've probably done one of these three things:

    1) free(p); ..... later, you used this indeterminate pointer value - OR
    2) free(p); ..... later, free(p); - OR
    3) p = malloc(sizeof *p); if(p != NULL) { modify(&p) somehow; free(p); }

    Like I said, I'm just guessing really (because I can't see the code),
    but any of the above could explain why your malloc arena is stuffed.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, May 7, 2007
    #2
    1. Advertising

  3. In article <>,
    Richard Heathfield <> wrote:

    >> To me it seems quite illogical that the malloc implementation should
    >> be able to die with a SIGSEGV(?) -


    >It's impossible to say for sure without seeing the code, but it's my
    >guess that you've probably done one of these three things:
    >
    >1) free(p); ..... later, you used this indeterminate pointer value - OR
    >2) free(p); ..... later, free(p); - OR
    >3) p = malloc(sizeof *p); if(p != NULL) { modify(&p) somehow; free(p); }


    Or (4) you've "run off the end" of some malloc()ed memory, perhaps
    modfying the 5th element of a 4 element array. Any of these things
    may mess up malloc()'s data structures, causing an obscure error some
    time later when you call malloc() or free().

    -- Richard

    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, May 7, 2007
    #3
  4. Joakim Hove

    Joakim Hove Guest


    > >1) free(p); ..... later, you used this indeterminate pointer value - OR
    > >2) free(p); ..... later, free(p); - OR
    > >3) p = malloc(sizeof *p); if(p != NULL) { modify(&p) somehow; free(p); }

    >
    > Or (4) you've "run off the end" of some malloc()ed memory, perhaps
    > modfying the 5th element of a 4 element array.


    Thank you for the suggestion, it indeed turned out to be an error
    along the these lines.

    > Any of these things
    > may mess up malloc()'s data structures, causing an obscure error some
    > time later when you call malloc() or free().


    I guess what kind of baffled me (somewhat naively ??) was that it was
    so easy to interfere with malloc()'s internal state. Anyway, now I
    know.

    Thank's again.

    Joakim
     
    Joakim Hove, May 7, 2007
    #4
  5. In article <>,
    Joakim Hove <> wrote:

    >I guess what kind of baffled me (somewhat naively ??) was that it was
    >so easy to interfere with malloc()'s internal state. Anyway, now I
    >know.


    There are many very effective tools that can help in tracking down
    this kind of error. Valgrind for example has probably saved thousands
    of person-years of tedious debugging.

    -- Richard

    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, May 7, 2007
    #5
  6. Joakim Hove

    Old Wolf Guest

    On May 7, 11:05 pm, Joakim Hove <> wrote:
    > > >1) free(p); ..... later, you used this indeterminate pointer value - OR
    > > >2) free(p); ..... later, free(p); - OR
    > > >3) p = malloc(sizeof *p); if(p != NULL) { modify(&p) somehow; free(p); }

    >
    > > Or (4) you've "run off the end" of some malloc()ed memory, perhaps
    > > modfying the 5th element of a 4 element array.

    >
    > Thank you for the suggestion, it indeed turned out to be an error
    > along the these lines.
    >
    > I guess what kind of baffled me (somewhat naively ??) was that it was
    > so easy to interfere with malloc()'s internal state. Anyway, now I
    > know.


    Some people are extremely sensitive about the speed and
    memory requirements of their programs that use malloc,
    preferring that it use as few bytes and picoseconds of
    overhead as possible, even if that means a fragile structure.

    Accordingly, compilers tend to make their malloc as fast as
    possible. However, some compilers offer a switch to use a
    more robust allocation scheme during debugging (or even
    in the release version, if the allocation is not a bottleneck);
    check your compiler documentation.
     
    Old Wolf, May 7, 2007
    #6
    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. Frank
    Replies:
    0
    Views:
    2,113
    Frank
    Aug 5, 2003
  2. manoj
    Replies:
    0
    Views:
    1,183
    manoj
    Jun 25, 2004
  3. Morris Dovey

    gdb SIGSEGV

    Morris Dovey, Feb 12, 2004, in forum: C Programming
    Replies:
    3
    Views:
    1,003
    Mark McIntyre
    Feb 14, 2004
  4. Nancy
    Replies:
    0
    Views:
    330
    Nancy
    Apr 5, 2006
  5. JNI SIGSEGV on AMD64

    , Aug 7, 2006, in forum: Java
    Replies:
    2
    Views:
    820
Loading...

Share This Page