Message-ID: <44786EAA.9020002@kleckner.net>
Date: Sat, 27 May 2006 08:22:18 -0700
From: Jim Kleckner <jek-cygwin1 AT kleckner DOT net>
User-Agent: Thunderbird 1.5 (Windows/20051230)
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>
In-Reply-To: <44775331.4070809@ukf.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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

Max Bowsher wrote:
> Hi,
>
> I compiled a C++ Python Extension, and found that it caused the Python
> interpreter process to silently die (with a *zero* exitcode!) when it
> attempted to load the extension module.
>
> I traced the problem to the line:
>   static ios_base::Init __ioinit;
> in <iostream>.
>
> It seems that when the module is dlopen()-ed, something involved in this
> static initializer terminates the process.
>
> [snip]

Thanks for the simple test case!  I was just preparing
to try to do this today.

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

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.

Perhaps Python is doing something similar and needs to
implement the same change implemented in GDB to
the signal handling?

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 *

Would the Python maintainer then consider whether these
changes are relevant to Python?

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

Normally, I keep a snapshot of an older Cygwin release
to protect against this kind of regression.  Unfortunately,
in my exuberance lately I find that my oldest snapshot
still exhibits this problem.  I have yet to find
a way to reliably down rev from the release itself.
I tried simply choosing "Prev" for all packages but
unfortunately in my haste didn't note what error message
occurred when trying that.

Thanks - Jim

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