This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [BZ #10631] Clarify malloc error diagnostics to avoid confusion


On Wed, Sep 19, 2012 at 1:39 PM, Rich Felker <dalias@aerifal.cx> wrote:
> 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’.

I fully agree that the error messages should not be implementation
specific and they should simply provide a unique reference point
for the developer or support to track down the issue.

However, the issue at hand is more about the structure of the message
and not about their content.

I would gladly accept a follow-on patch to change the error messages to
something meaningful.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]