[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes
SourceForge.net
noreply at sourceforge.net
Tue Oct 11 23:14:18 CEST 2005
Bugs item #1311784, was opened at 2005-10-03 15:18
Message generated for change (Comment added) made by adalx
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: Adal Chiriliuc (adalx)
Date: 2005-10-12 00:14
Message:
Logged In: YES
user_id=1067739
I'm not so sure that setting an unsupporting signal and
expecting the operation to not crash/abort is valid ANSI-C:
http://www.ndp77.net/ansi_c/ac04.htm#4.7
Quote: "The complete set of signals, their semantics, and
their default handling is implementation-defined; all signal
values shall be positive."
Listed under "Implementation-Defined Behavior":
http://msdn.microsoft.com/library/en-us/vclang/html/_CLANG_The_signal_Function.asp
The list of supported signals:
http://msdn.microsoft.com/library/en-us/vclib/html/_CRT_signal.asp
I'll also switch to VS 2005 soon. This should be fixed, even
if the binary distribution will continue to be compiled
using VS .NET 2003.
----------------------------------------------------------------------
Comment By: Peter Klotz (pete_icoserve)
Date: 2005-10-11 16:10
Message:
Logged In: YES
user_id=299547
I think we misunderstand each other. My intention was not to
force anyone to change his compiler.
AFAIK there is no AMD64 support prior to VS2005 (i.e.
compiler version 14.00). Therefore as soon as one has to
compile for AMD64 he runs into the initial problem of this
bug report.
The only thing I am asking for is to incorporate a
(hopefully small) VS2005 specific workaround in the source
code of Python.
The default compiler should remain VS2003 (i.e. compiler
version 13.10). So no one has to change his compiler.
However people that are forced to use VS2005 do not run into
this specific problem anymore.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-10-10 23: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 10: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 12: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 11: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 22: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 21: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 16: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
More information about the Python-bugs-list
mailing list