X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: 1.5.19: changes have broken Qt3
Date: Wed, 24 May 2006 13:23:30 +0100
Message-ID: <04d301c67f2c$ddbac010$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20060524120700.GL13907@ns1.anodized.com>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

On 24 May 2006 13:07, clayne AT anodized DOT com wrote:

> On Wed, May 24, 2006 at 11:40:58AM +0100, Dave Korn wrote:
>>> Actually, is this really a fault in gdb? Cygwin is throwing a SIGSEGV
>>> signal, correct? GDB does what it's told, stops on SIGSEGV by default.
>>> 
>>> -cl
>> 
>>   But it doesn't interact properly with cygwin's exception handling ->
>> signal mechanism, and the task dies, when it should just run on.
>> 
>>   Anyone who's doing any serious debugging on Cygwin very seriously wants
>> to build their own gdb and insight from current CVS.  It's much improved
>> of late. 
> 
> Right, or bless their sanity - as it won't last long. But I'm just trying to
> debate that it's no "lacking" of gdb that it's catching SIGSEGV signals
> which are being artificially generated by cygwin.

  It's not a SIGSEGV.  It's actually a protection fault, which is one variety
of exception.  Cygwin's job is to catch the faulting access using a structured
exception handler and translate it into a signal - if, and only if, the
exception does in fact represent an event that should be reported to userland
as a signal.  If, as in this case, the exception is part of cygwin's internal
access checking and should not be reported as a signal to userland, cygwin's
job is to catch the faulting access and /not/ translate it into a signal.

  Now bear in mind that we're not talking about any old version of gdb here:
we're very specifically discussing the cygwin-targeted version of gdb.  That
means it should understand about cygwin's signal handling mechanism, and it
should know that some exceptions will be translated into signals and others
will not, and it should leave cygwin to handle that and only report a SIGSEGV
(or any other kind of signal) when cygwin decides to turn a particular
exception into a signal, and not when it doesn't.  It's an old
hangover/win32-ism that it intercepts all the windows exceptions and attempts
to interpret them to the user as SIGs of some kind; might make sense if it was
attempting to debug a windows native (msvcrt-based) application, but does not
make sense for a cygwin app these days; long long ago, it was a reasonable
design compromise when gdb was first being targeted at wintel platforms.

> What's the design mechanism for the entire 'check for non-initialized space
> and segfault if uninitialized' when it comes to statically initialized
> pthreads objects in the first place, btw? Why not just have pthread_mutex_t
> (for example actually be a pthread_mutex_t instead of it being a type'd
> pointer to the real pthread_mutex_t? Why dynamically initialize space for
> it at all via the check bunk memory->throw fault->alloc real memory for
> real pthread_mutex_t as opposed to "initialiize the mutex->if bunk space,
> segfault as usual" ? 

  In order to comply with the complex way the POSIX spec allows you to have
*either* static linktime initialisation *or* dynamic runtime initialisation of
all these objects.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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