delorie.com/archives/browse.cgi | search |
X-Spam-Check-By: | sourceware.org |
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> |
X-IsSubscribed: | yes |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
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 |
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/
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |