Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Date: Mon, 30 Dec 2002 23:39:13 -0500 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: Heads up: *possible* bug in cygwin Message-ID: <20021231043913.GA26944@redhat.com> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <3E05BD05.5090408@ece.gatech.edu> <3E0DDE19.1060903@ece.gatech.edu> <3E10A7AE.20405@ece.gatech.edu> <3E10C29B.2010709@ece.gatech.edu> <3E111AAF.3090008@ece.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E111AAF.3090008@ece.gatech.edu> User-Agent: Mutt/1.5.1i On Mon, Dec 30, 2002 at 11:18:55PM -0500, Charles Wilson wrote: > >>If somebody with a debuggable cygwin kernel could look into this, I'd >>appreciate it. I'll try to follow up on my own, but it takes FOREVER to >>do a 'cvs update' on the cygwin source tree over a 28.8k modem... > >Sigh. Finally built a debuggable cygwin from current CVS. Here's the >stacktrace from the SIGSEGV. Problems "in the bowels" of malloc are invariably caused by memory corruption, like double freeing of a pointer, overrunning of a buffer, ignoring of OOM conditions, etc. Given that the malloc in cygwin (to say nothing of Doug Lea's malloc) goes through a fairly heavy workout every day, I'd suspect the application before I'd suspect cygwin. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/