Re: newlib/libc/stdlib/mallocr.c

[Christopher Faylor <cgf at redhat dot com>]

On Tue, Apr 02, 2002 at 01:33:30PM -0500, Earnie Boyd wrote:
>Christopher Faylor wrote:
>>>I would get segmentation faults within mallocr.c.  The first time it
>>>occurred was the originating call was within the code I was adding.  I
>>>modified the code a bit and that caused the malloc's in environ.cc to
>>>issue the segmentation faults in mallocr.c.  If you need to know
>>>exactly where in mallocr.c that was causing the problem I can most
>>>likely reproduce it to get the failure point.
>>
>>SEGVs are invariably a sign of attempts to free memory that hasn't been
>>allocated.
>
>I wasn't freeing memory I was mallocing memory.  Once I've finished my
>annual disk cleaning job I'll try to reproduce the problem.

Come on.  Let's not be literal here.  It's a sign of malloc pool
corruption.  Sometimes this is caused by double freeing of memory prior
to a malloc.  Sometimes it's caused by overrunning a buffer allocated
by malloc.  Standard stuff.

This sounds suspiciously like the standard cygwin complaint of assuming
that a standard function like malloc/free has a basic problem which
would cause random SEGVs.  To assume such a thing would also require the
assumption that thousands of programs out there are inadvertently
working around the problem in unknown ways.

The alternative is to assume that there is something wrong with *your*
program and debug that.

I'm aware that adding a MMAP option to malloc may cause the problem not
to manifest but that is certainly not a sign that this is fixing the
problem rather than working around it.  You won't know what the actual
problem is until you debug it.

cgf