Message-ID: <44787848.1BD5F4CF@dessent.net>
Date: Sat, 27 May 2006 09:03:20 -0700
From: Brian Dessent <brian AT dessent DOT net>
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin G++ bug? - Python Extension module #including <iostream>    dies  before initialization
References: <44775331 DOT 4070809 AT ukf DOT net> <44786EAA DOT 9020002 AT kleckner DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Jim Kleckner wrote:

> This appears related to the signal handling problem that GDB experiences
> and documented at length.  One starting point for this discussion is the
> thread here:
>  http://www.cygwin.com/ml/cygwin/2006-05/msg00691.html

I don't see any way that these two issues are related.

> GDB is inserting a signal handler ahead of Cygwin that catches
> signals used to detect valid/invalid objects and GDB is then
> failing when it classifies those signals as SIGSEGV.
> It happens with the iostream usage because of a static
> initializer that uses a mutex for safety.  The fix involved
> a small change to cygwin along with a small change to
> GDB so that the exception used to detect a bad pointer
> by cygwin would not be caught by GDB as a SIGSEGV.
> The fix side of Cygwin is not yet released (but it is in
> snapshots) and the fix side of GDB is checked in but
> can't be released until Cygwin dll is released.

That is not really true.  GDB does not "install" anything resembling a
signal handler.  In fact, none of this has anything to do with posix
style signals per se, because this happens at a much lower level, at the
Windows SEH level.  Signals are an artificial construct that are
emulated by Cygwin, and don't actually exist on Windows.

The way it works is that GDB uses the native windows debug API.  Using
this API whenever an exception occurs the inferior is halted and control
returns to the debugger.  The debugger then has the choice of handling
the fault (e.g. notifying the user and allowing them to take action) or
doing nothing and passing it through to whatever existing handler is in
place in the inferior.

The only change that was made to GDB was that it was made aware of the
memory space that cygwin1.dll is loaded into, and so that it knows to
always pass-thru any faults occuring in that space.  GDB is still
alerted on every one of them, because that is how the Windows debug API
works, it just knows to pass-thru any that occur in the cygwin DLL, so
that the installed cygwin handler takes care of it.

As you can see, this all is contingent upon a program like GDB using the
Windows debug API.  Without that, the entire issue is irrelevant, so I
can't see how this possibly would apply to Python.

> Could someone provide a pointer to the GDB change?
> (Yes, I looked into the change logs for GDB around Feb
> but nothing stood out as relevant).
>  *http://tinyurl.com/fqpb9 *

That is the toplevel ChangeLog for the 'src' directory.  The only files
in that directory are common build infrastructure shared by binutils,
gcc, cygwin, newlib, and a bunch of other random stuff.  I.e. that is
not the place to be looking for such a change.

As I mentioned in <http://cygwin.com/ml/cygwin/2006-04/msg00936.html>
the GDB side of the fix was posted in
<http://sourceware.org/ml/gdb-patches/2006-02/msg00352.html>.

> Until this is solved, all DLLs that are used by Python
> and use C++ with iostreams will fail silently in this way.

I don't know why this Python failure is occuring, but I can't see any
way that it is related to the GDB issue, other than the fact that users
trying to debug the Python failure might see the GDB failure and think
there was some kind of connection when there isn't any.

> Normally, I keep a snapshot of an older Cygwin release
> to protect against this kind of regression.  Unfortunately,

You should google for the Cygwin time machine.

But do note that using an older Cygwin DLL with newer packages is a very
tricky thing due to API changes; the DLL is only designed to be
backwards compatible, not forwards compatible.  In the limiting case all
binaries on the system must be the same age or older as the Cygwin DLL,
and this is not a condition that is guaranteed by simply selecting
"Prev" for everything because the version considered "Prev" is at the
mercy to each package maintainer and follows no overall rules.

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/