Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Mon, 30 Dec 2002 23:39:13 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Heads up: *possible* bug in cygwin Message-ID: <20021231043913.GA26944@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <3E05BD05 DOT 5090408 AT ece DOT gatech DOT edu> <3E0DDE19 DOT 1060903 AT ece DOT gatech DOT edu> <3E10A7AE DOT 20405 AT ece DOT gatech DOT edu> <3E10C29B DOT 2010709 AT ece DOT gatech DOT edu> <3E111AAF DOT 3090008 AT ece DOT gatech DOT 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/