Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-developers-owner AT cygwin DOT com
Message-ID: <3CA9CD1B.CC324CF3@yahoo.com>
Date: Tue, 02 Apr 2002 10:24:11 -0500
From: Earnie Boyd <earnie_boyd AT yahoo DOT com>
Reply-To: Earnie Boyd <Cygwin-Developers AT cygwin DOT com>
MIME-Version: 1.0
To: cygwin-developers AT cygwin DOT com
Subject: Re: newlib/libc/stdlib/mallocr.c
References: <3CA9A7A9 DOT 1A8AD3C5 AT yahoo DOT com> <20020402151655 DOT GB17969 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com