Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3E11AD26.8050506@ece.gatech.edu>
Date: Tue, 31 Dec 2002 09:43:50 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Heads up: *possible* bug in cygwin
References: <E18PoeB-0000fC-00 AT quimby DOT gnus DOT org> <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> <20021231043913 DOT GA26944 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:
> 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.

I would too -- but I can't see where any of the arguments to the 
functions, or any of the operations within the glib subroutines along 
the way, do any of that.  It all =seems= okay, but I'll probably have to 
pull out pencil and paper and keep track of all the pointers by hand. 
Or can I just turn on -DDEBUG when compiling malloc.cc...

Plus, glib-2.0.7 is at least as well tested as cygwin (and might be 
close to as well tested as dlmalloc). It's hard to imagine that a buffer 
overrun or double-free was overlooked in glib's own testsuite, given 
that folks on non-cygwin platforms can use stuff like purify and 
electricfence when they test.

And finally, that doesn't explain why the *same code*, *unchanged*, 
worked on May 1, 2002, but doesn't now.  I wish I had the cygwin dll and 
importlib from then, so I could eliminate that variable...

Hmmm...glib does a lot of testing against NULL to determine whether a 
pointer has been initialized -- but declares these pointers as
   gpointer foo;
not
   gpointer foo = NULL;
Did gcc (pre 3.2) automatically initialize data to 0, while gcc-3.2 does 
not?  Hmmm...waitaminute, I do have gcc2 installed...

--Chuck


--
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/