[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes

Mon Oct 10 22:13:05 CEST 2005

Bugs item #1311784, was opened at 2005-10-03 14:18
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Klotz (pete_icoserve)
Assigned to: Nobody/Anonymous (nobody)
Summary: python.exe 2.4.2 compiled with VS2005 crashes

Initial Comment:
The C runtime library shipped with Visual Studio 2005
performs strict checking of parameters.

In function initsignal() in file
Modules\signalmodule.c, an iteration over all signals
from 1 to NSIG is performed.

The function PyOS_getsig() is called with each of these
integer values. PyOS_getsig() then calls signal() with
the given value which leads to the crash.

According to signal.h from VS2005 only these signals
are allowed:

#define SIGINT          2     
#define SIGILL          4     
#define SIGABRT_COMPAT  6     
#define SIGFPE          8     
#define SIGSEGV         11    
#define SIGTERM         15    
#define SIGBREAK        21    
#define SIGABRT         22    

A solution would be to restrict the loop in
initsignal() to the above values under Windows.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2005-10-10 22:13

Message:
Logged In: YES 
user_id=21627

Yes, I really do. Users have protested a lot when we
switched from VC6 to VS.NET2003, because they had to buy new
compilers. We cannot reasonably force another compiler
switch on them next year. However, this is off-topic for
this bug report, please discuss it on python-dev.

As for 64-bit windows support: I happily build 64-bit
Windows binaries all the time with VS.NET2003, see
www.python.org/2.4.2. There are no AMD64 binaries released,
but extending the technology to support, say, the AMD64 SDK
compiler would be possible. Patches to the actual code are
greatfully accepted.

----------------------------------------------------------------------

Comment By: Peter Klotz (pete_icoserve)
Date: 2005-10-10 09:05

Message:
Logged In: YES 
user_id=299547

Do you really think ignoring/skipping VS2005 is a proper
solution?

I am currently porting our software to 64Bit Windows
(AMD64/EM64T) and the only compiler supporting this is the
one included in VS2005.

If Python does not support VS2005 everyone needing a 64Bit
version of Python is forced to locate and fix this problem
on his own.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2005-10-08 11:56

Message:
Logged In: YES 
user_id=21627

Can somebody please study the source of the C runtime of
VS2005 (probably needs to be requested specifically during
installation), to find out whether more generic solutions
are available. Possible solutions include:
- don't call signal, but call an alternative function
instead which won't cause a crash
- set some magic variable, disabling the error checking
- fetch the list of supported signals from somewhere (at
compile time or at run time), and iterate over that list.

Anyway, I don't see the official Python 2.5 release built
with VS 2005, so this is a minor issue - I rather expect
Python to skip VS 2005, and go right to the version that
succeeds it.

----------------------------------------------------------------------

Comment By: Peter Klotz (pete_icoserve)
Date: 2005-10-04 10:02

Message:
Logged In: YES 
user_id=299547

I would leave the code for pre-VS2005 compilers as is and
introduce a specific workaround for VS2005 and all following
compilers.

Something like this comes to my mind:

#if defined (_WIN32) && _MSC_VER >= 1400
...
#endif

This works for 32 and 64 bit platforms since _WIN32 is
defined in both cases.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 21:54

Message:
Logged In: YES 
user_id=33168

Do you suggest this be special cased for VS2005 specifically
or Windows in general (ie, any version/compiler)?

----------------------------------------------------------------------

Comment By: Peter Klotz (pete_icoserve)
Date: 2005-10-03 20:10

Message:
Logged In: YES 
user_id=299547

VS2005 is still not released. 

It is scheduled for November 7th 2005. I tested with CTP 
(Community Technology Preview) August 2005.

However I doubt they will change the behavior of their C library 
at this point of development.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-10-03 15:05

Message:
Logged In: YES 
user_id=6656

Is VS2005 actually out now then?  This behaviour violates the C standard, 
as far as we can tell, so we when VS2005 was in beta we hoped that they 
would fix it for the final release.

If it is released, though, I guess we need to do something like you suggest 
(along with some colourful comments, I guess).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470