This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin G++ bug? - Python Extension module #including <iostream> dies before initialization

Max Bowsher wrote:

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.


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:

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).
* *

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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]