Message-ID: <4478CDD5.E259C90F@dessent.net>
Date: Sat, 27 May 2006 15:08:21 -0700
From: Brian Dessent <brian@dessent.net>
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: 1.5.19: changes have broken Qt3
References: <044e01c67e8f$0abed720$a501a8c0@CAM.ARTIMI.COM> <447350C4.1080604@freenet.de> <20060523182326.GB6138@trixie.casa.cgf.cx> <4473607C.2070806@freenet.de> <44741E31.665A1B7@dessent.net> <447420D1.8090909@freenet.de> <4474250C.AA4A166@dessent.net> <44744F28.905@freenet.de> <44789FCB.2FFF9168@dessent.net> <4478B5D3.4000806@freenet.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: cygwin@cygwin.com
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Ralf Habacker wrote:

> There is only one case where I still believe that there may be a problem.
> If a pthread_mutexattr_t is constructed on the stack and the magic class
> membere is be exactly the predefined value, pthread_mutexattr_init()
> will return EBUSY, although there is no good object, it is only by random.

I believe this has been hashed out on the list before as well.  I think
the conclusion is that the app needs to check the return values so that
it can cope with this case.  I don't have a link to the thread handy.

> My currently conclusion is that there are rare conditions in the pthread
> and/or exception stuff, which corrupts the stack and that there is more
> work required to find out the problem.

This I don't doubt, but I think it will just require someone digging
in.  If you can whittle down the qt3 stack overflow crash to a testcase,
then there's a good chance someone reading will give it more attention.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/