Mailing-List:	contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-developers/>
List-Post:	<mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID:	<02b001c15b5b$c4d61300$0200a8c0@lifelesswks>
From:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>,
	"Jonathan Kamens" <jik AT curl DOT com>
Cc:	<cygwin-developers AT cygwin DOT com>
References:	<3BD4635D DOT 1060208 AT ece DOT gatech DOT edu> <20011022142729 DOT A10309 AT redhat DOT com> <20011022192430 DOT 3581 DOT qmail AT lizard DOT curl DOT com> <20011022193036 DOT 3609 DOT qmail AT lizard DOT curl DOT com> <20011022203136 DOT 5144 DOT qmail AT lizard DOT curl DOT com> <20011022203747 DOT 5162 DOT qmail AT lizard DOT curl DOT com> <02a201c15b5b$7910a4d0$0200a8c0 AT lifelesswks>
Subject:	Re: 1.3.4 status?
Date:	Tue, 23 Oct 2001 10:43:43 +1000
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime:	23 Oct 2001 00:48:25.0636 (UTC) FILETIME=[6C5EDE40:01C15B5C]

----- Original Message -----
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Jonathan Kamens" <jik AT curl DOT com>
Cc: <cygwin-developers AT cygwin DOT com>
Sent: Tuesday, October 23, 2001 10:41 AM
Subject: Re: 1.3.4 status?


> My 2c on this is that this could be a lot worse than a malloc issue...
> even though it is occuring at process exit.
>
> GCC optimisation can change the code substantially as you step up
                             machine
> layers.
>
> i.e. on common problem squid had was that a function ended up XOR'ing
         e
> variable foo with itself, before trying to use it! (Oh, it was _not_
> meant to be 0). That resulted in the *BSD's requiring special
configure
> lines to disable -O2 for that OS release, and yet another gcc version
> test in the configure script.
>
> So, I'd start of by hand checking the faulting line of assembly, to
see
                off
> that is *should* work if everything where normal, and then work back
       it
> through the stack trace doing the same thing. If you get past the
exit()
> stuff, then malloc is a thing to try. I'm not sure which is faster,
this
                                                         way
> is just my 2c.
>
> Rob

That was almost illegible - sorry!

- Raw text -