Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Tue, 2 Apr 2002 13:31:41 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: newlib/libc/stdlib/mallocr.c
Message-ID: <20020402183141.GA24930@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <3CA9A7A9 DOT 1A8AD3C5 AT yahoo DOT com> <20020402151655 DOT GB17969 AT redhat DOT com> <3CA9CD1B DOT CC324CF3 AT yahoo DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3CA9CD1B.CC324CF3@yahoo.com>
User-Agent: Mutt/1.3.23.1i

On Tue, Apr 02, 2002 at 10:24:11AM -0500, Earnie Boyd wrote:
>Christopher Faylor wrote:
>> 
>> On Tue, Apr 02, 2002 at 07:44:25AM -0500, Earnie Boyd wrote:
>> >In my modifying Cygwin source for MSYS I began having issues with malloc
>> >and the offending pieces being within this source.  I noticed that the
>> >HAVE_MMAP macro was set to 0 by default instead of 1 by default as
>> >Dave's documentation says that it does.  Modifying the macro value to 1
>> >caused all of the problems I was experiencing to disappear.
>> >
>> >Do other Cygwin developers see benefit for a patch to newlib?
>> 
>> Can you describe the problem?  I guess it's possible that allowing this code
>> would fix the out-of-memory heap issues we continually have but, the last time
>> I benchmarked this, using mmap had a performance hit.  This was on UNIX but
>> I can't imagine it isn't the same on cygwin.
>> 
>
>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.

cgf