Informative assertion failure



  • So, I'm working with some research code, and lo and behold, when I run with an input size of 64 I get a failed assertion due to a malloc.  I present to you, the full glory of this highly informative and useful assertion:

    malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) 
    &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && 
    old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct 
    malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) 
    && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)'
     failed.
    

    ....thanks assertion writing guy. Thanks a lot.



  •  Oh, yeah.  You gotta check (old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0).  I mean, this is a pretty obvious, day 1 thing here.  One time I didn't verify that (old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) -
    __builtin_offsetof (struct malloc_chunk, fd)))) && old_size ==

    1. || ((unsigned long) (old_size) >= (unsigned
      long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
      (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) &&
      ((old_top)->size & 0x1) && ((unsigned long)old_end &
      pagemask) == 0)
      , and all hell broke loose.  Needless to say, we were cleaning up the charred remains for weeks.

      What's that old saying?  "Some people, when confronted with a problem, think, "I know, I'll make sure (old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) -
      __builtin_offsetof (struct malloc_chunk, fd)))) && old_size ==

    2. || ((unsigned long) (old_size) >= (unsigned
      long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
      (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) &&
      ((old_top)->size & 0x1) && ((unsigned long)old_end &
      pagemask) == 0)
      is false."  Now they have two problems."



  • You managed to clean up the remains in weeks? When I forgot to verify that (old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0) it took us months to get the burned remains out of the carpets.



  • @DescentJS said:

    You managed to clean up the remains in weeks? When I forgot to verify that (old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0) it took us months to get the burned remains out of the carpets.
    Ah, but we were prepared.  Our floors were all concrete, making it a quick fix when (old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) -
    __builtin_offsetof (struct malloc_chunk, fd)))) && old_size ==

    1. || ((unsigned long) (old_size) >= (unsigned
      long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
      (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) &&
      ((old_top)->size & 0x1) && ((unsigned long)old_end &
      pagemask) == 0)
      failed.  The real time consumer was sifting through the rubble for organic matter, so the widows would have something to bury.  Many a good man lost his life in the (old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) -
      __builtin_offsetof (struct malloc_chunk, fd)))) && old_size ==
    2. || ((unsigned long) (old_size) >= (unsigned
      long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
      (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) &&
      ((old_top)->size & 0x1) && ((unsigned long)old_end &
      pagemask) == 0)
      Disaster of 2007.  I still have nightmares.  Sometimes I wake up in a cold sweat, pleading with the heavens to confirm that (old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) -
      __builtin_offsetof (struct malloc_chunk, fd)))) && old_size ==
    3. || ((unsigned long) (old_size) >= (unsigned
      long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
      (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) &&
      ((old_top)->size & 0x1) && ((unsigned long)old_end &
      pagemask) == 0)
      .



  • An assert is a statement of something, that may never happen unless there is a bug in the code around assert itself -- or the memory is corrupt in which case anything may happen. It especially is not meant to signify bug in the calling code. So in neither case would understanding the assert help you and for the maintainer of that code it would probably be clear.

    Since it's unlikely you'll hit a bug in the most used function of standard library, it's probably the second reason. You may want to run your code under valgrind or with the DUMA (formerly efence) library.

    Oh, note, that assert just prints out textual representation of it's argument but it has macros expanded and all whitespace reduced to single space. So it's probably much more readable on the line 3096 in malloc.c.



  • @Bulb said:

    An assert is a statement of malloc.c:3096: sYSMALLOc: Assertion (old_top == (((mbinptr) (((char *) &amp;((av)-&gt;bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) &amp;&amp; old_size == 0) || ((unsigned long) (old_size) &gt;= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) &amp; ~((2 * (sizeof(size_t))) - 1))) &amp;&amp; ((old_top)-&gt;size &amp; 0x1) &amp;&amp; ((unsigned long)old_end &amp; pagemask) == 0)', that may never happen unless there is a ((av)-&gt;bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) &amp;&amp; old_size == 0) in the code around assert itself -- or the memory is corrupt in which case ~((2 * (sizeof(size_t))) - 1))) &amp;&amp; ((old_top)-&gt;size &amp; 0x1) &amp;&amp; ((unsigned long)old_end &amp; pagemask) == 0) may happen. It especially is <i>not</i> meant to signify bug in the calling code. So in neither case would understanding the assert help <i>you</i> and for the maintainer of that code it would probably be malloc.c:3096: sYSMALLOc: Assertion(old_top == (((mbinptr) (((char *)
    &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
    malloc_chunk, fd)))) && old_size == 0) || ((unsigned long)
    (old_size) >= (unsigned long).

    Since it's unlikely you'll hit a bug in the most used function of standard library, it's probably the second __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0). You may want to run your code under valgrind or with the DUMA (formerly efence) library.

    Oh, note, that assert just prints out ((unsigned long)old_end & pagemask) == 0) of it's argument but it has macros expanded and all whitespace reduced to (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))). So it's probably much more readable on the line 3096 in malloc.c.

     

    I fixed your gibberish for you because just couldn't understand a word of it.



  •  

    I briefly took a stab at reorganizing that mess into something more readable.  but quickly decided it just wasn't worth the effort.  Are you sure that the person who wrote this is sane?  are you sure they are not part of some ancient evil cult that wishes to align the stars and awaken cthullu?



  • I find the sizeof(size_t) snippet particularly interesting for some reason.

    Anyway.. this page seems to be the current result of feeling lucky with "mbinptr".



  • @galgorah said:

    Are you sure that the person who wrote this is sane?  are you sure they are not part of some ancient evil cult that wishes to align the stars and awaken cthullu?

     They say that BASIC rots the brain; that Java makes you a pansy. But they fail to mention that C eventually drives you mad. Mad!

    [Mod: Quoting: it's one of the few things CS can actually do. -bs]



  • @Bulb said:

    An assert is a statement of something, that may never happen unless there is a bug in the code around assert itself -- or the memory is corrupt in which case anything may happen. It especially is not meant to signify bug in the calling code. So in neither case would understanding the assert help you and for the maintainer of that code it would probably be clear.

    Since it's unlikely you'll hit a bug in the most used function of standard library, it's probably the second reason. You may want to run your code under valgrind or with the DUMA (formerly efence) library.

    Oh, note, that assert just prints out textual representation of it's argument but it has macros expanded and all whitespace reduced to single space. So it's probably much more readable on the line 3096 in malloc.c.

    Some people take this forum way too seriously.



  • @blakeyrat said:

    Some people take this forum way too seriously.

    When they think assertinon like:

      assert((old_top == initial_top(av) && old_size == 0) ||
             ((unsigned long) (old_size) >= MINSIZE &&
              prev_inuse(old_top) &&
              ((unsigned long)old_end & pagemask) == 0));
    

    is not a WTF.



  • @Bulb said:

    When they think assertinon like:

      assert((old_top == initial_top(av) && old_size == 0) ||
             ((unsigned long) (old_size) >= MINSIZE &&
              prev_inuse(old_top) &&
              ((unsigned long)old_end & pagemask) == 0));
    

    is not a WTF.

    Who?


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.