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-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
_______________________________________________
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to