Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Date: Wed, 3 Apr 2002 09:28:48 -0500 From: Christopher Faylor To: cygwin-developers AT cygwin DOT com Subject: Re: newlib/libc/stdlib/mallocr.c Message-ID: <20020403142848.GE4053@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> <20020402183141 DOT GA24930 AT redhat DOT com> <3CA9F97A DOT 9EC8B967 AT yahoo DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CA9F97A.9EC8B967@yahoo.com> User-Agent: Mutt/1.3.23.1i 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