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
Date: Wed, 12 Sep 2001 01:21:21 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Quick testfeedback...
Message-ID: <20010912012121.A2889@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F166 AT itdomain002 DOT itdomain DOT net DOT au> <20010911230429 DOT A1898 AT redhat DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20010911230429.A1898@redhat.com>
User-Agent: Mutt/1.3.21i

On Tue, Sep 11, 2001 at 11:04:29PM -0400, Christopher Faylor wrote:
>On Wed, Sep 12, 2001 at 12:46:01PM +1000, Robert Collins wrote:
>>>-----Original Message----- From: Christopher Faylor
>>>[mailto:cgf AT redhat DOT com]
>>>>Which is why I was so mystified and concerned about it.
>>>
>>>I wasn't saying that there were even errors, necessarily.  I thought
>>>that there might have been some signal generated.  It could be a
>>>harmless signal like SIGUSR1 or SIGCHLD or something.
>>
>>Ok, well I'm going to commit the critical section stuff - Jason
>>apparently got the same segv with and without the patch.  And then
>>we're good to go I think.
>
>I don't think so.  We still have a mysterious signal, probably a SEGV
>to worry about.

Jason, could you see if you can recreate any problems with broadcast
with the latest CVS?

If not, I guess this is a wrap.

(Unless Egor wants to modify some syscalls to protect against bad
pointers)

I think I figured out where the "signal" was coming from.  The main
thread sets the signal_arrived event when the process is about to
exit.  This would be detected by sleep, causing sleep to decide
to call a nonexistent signal handler.

Phew.  This is a long-standing bug that would only be tickled in
multi-threaded applications.

It would be nice to verify that the "broadcast" problems are gone,
though.

cgf

(Who's fully prepared for the fact that Jonathan will now get gdb
running and will provide a stack trace to the "make segvs" problem that
has been haunting us, causing me to delay the release *again* while we
try to fix it)