This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [BZ #10631] Clarify malloc error diagnostics to avoidconfusion
On Wed, Sep 19, 2012 at 05:24:30PM +0200, Marek Polacek wrote:
> On Wed, Sep 19, 2012 at 10:58:40AM -0400, Carlos O'Donell wrote:
> > Does it actually matter what you or I *like*?
> >
> > What do our users need to see?
> >
> > > I'd be happy also with just:
> > > *** in ./a.out: free(): invalid next size (fast): 0x084ed538 ***
> >
> > That's just as terse as the original and doesn't help our users, it's not even clear
> > that this an error :-(
>
> You're right.
>
> > What about this?
> > ~~~
> > *** Error `free(): invalid next size (fast)' in `./a.out' at 0x084ed538 ***
> > ~~~
>
> Yep, I really like this one ;) But let's hear what others think. Thanks,
I think this would be more informative:
*** Error: âfree(): heap corruption detectedâ in â./a.outâ at 0x084aed538 ***
the idea being that users (either application users, or programmers
using glibc) do not need to know about the glibc implementation
details (next size, fast), only that the application is guilty of heap
corruption. Including the words âheap corruptionâ will help users
searching for solutions in understanding whatâs wrong with the program.
If you want to be even more verbose:
*** Error: free() cannot deallocate memory at %p because internal
bookkeeping information at %p contains an invalid value. This is
usually the result of heap corruption, possibly a buffer overflow
that took place earlier during program execution. This call to
free() was made from %p in â%sâ.
Rich