[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes
SourceForge.net
noreply at sourceforge.net
Wed Dec 21 06:43:30 CET 2005
Bugs item #1311784, was opened at 2005-10-03 05:18
Message generated for change (Comment added) made by nnorwitz
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: Closed
Resolution: Duplicate
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: Neal Norwitz (nnorwitz)
Date: 2005-12-20 21:43
Message:
Logged In: YES
user_id=33168
If you track down the references you will find the change
has been made to the CM repository in revision 41554.
See patch:
http://sourceforge.net/tracker/index.php?func=detail&aid=1350409&group_id=5470&atid=305470
The work around is to download the source and build python
yourself, ensuring the patch is applied.
How do you propose we backpatch already released versions?
----------------------------------------------------------------------
Comment By: Kirjah Salys (khepri)
Date: 2005-12-20 21:28
Message:
Logged In: YES
user_id=488858
VS2005 is out, and this bug still occurs in the release
version (of both Python and VS2005). Is there any workaround
for this? I can't see any being posted, and I replaced my
system-wide compiler. It wouldn't exactly be feasible to
accept the basic binary distribution or 'downgrade' my
compiler in any event (Python has library binary
compatibility problems in a wide variety of cases with
external programs/libraries). Is Python's official stance to
still pretend that VS2005 doesn't exist?
And while it's probable that this violates standard (what
compiler/library doesn't nowadays? *bleh*), and the
'deprecation warnings' get on nerves, this causes Python to
crash "for no good reason" when compiled with it.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-10-12 00:56
Message:
Logged In: YES
user_id=21627
Thanks for pointing out the earlier report, closing this one
as a duplicate.
Re: the platform SDK includes the same CRT: I somewhat doubt
that statement. In my copy of the SDK, I have a msvcrt.dll
version 6.10.2207.0, and the CRT sources don't have
assertions in them. I can't ultimately test this, though, as
I don't have the hardware.
Re: it's an assertion. So does everybody agree that this is
not conforming to ISO C? It should be worked-around in
Python, sure, but preferably only after the release of the
compiler, and preferably only after researching alternative
solutions in the CRT sources of VS2005.
----------------------------------------------------------------------
Comment By: Peter Klotz (pete_icoserve)
Date: 2005-10-12 00:01
Message:
Logged In: YES
user_id=299547
Re: AMD64 compilers are available as part of the current
platform SDK as available to MSDN subscribers (not through
the free SDK download), and also reportedly available as
part of the DDK.
It is true that the current platform SDK supports AMD64 but
the included compiler has version number 14.00 and comes
with the same C runtime that is shipped with VS2005.
I should have stated 'there is no AMD64 support prior to cl
14.00' rather than 'there is no AMD64 support prior to VS2005'.
Nevertheless if you have to compile for AMD64 under Windows
you have to use cl 14.00 and you cannot avoid the C runtime
library showing the new signal behavior.
----------------------------------------------------------------------
Comment By: Adal Chiriliuc (adalx)
Date: 2005-10-11 17:17
Message:
Logged In: YES
user_id=1067739
This has been reported before. Maybe these two bugs should
me merged somehow:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470
The older bug report states that it's an assertion error,
not a crash. That's consistent with the recent security
clean-up of the CRT in VS 2005. I don't think that MS will
fix this, since they are the ones which added the extra
assertions. I've looked through the source code of the .NET
2003 version and it works as in ANSI-C (SIG_ERR is returned
for unknown signals).
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-10-11 16:36
Message:
Logged In: YES
user_id=21627
Re: this should be fixed: It certainly should (but doing so
is less important than fixing problems which affect the
actual distribution).
Re: Conformance with ISO C. "implementation-defined" is not
"undefined". Implementation-defined behaviour must be within
the specified behaviour, chosing one of possible
alternatives. The alternative to chose is the specific set
of signals to support. For unsupported signals, the quoted
text specifies:
"If the request can be honored, the signal function returns
the value of func for the most recent call to signal for the
specified signal sig . Otherwise, a value of SIG_ERR is
returned and a positive value is stored in errno ."
So if signal() would return SIG_ERR, this would be
conformant. If execution would be aborted, this would not be
conformant. Unfortunately, this report does not tell which
of these it is: it only says "performs strict checking of
parameters", without saying what the effect of this checking
is. "leads to a the crash" suggests that there is a crash of
some kind, though.
Re: no AMD64 compiler prior to VS2005: this is not true.
AMD64 compilers are available as part of the current
platform SDK as available to MSDN subscribers (not through
the free SDK download), and also reportedly available as
part of the DDK.
----------------------------------------------------------------------
Comment By: Adal Chiriliuc (adalx)
Date: 2005-10-11 14: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 06: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 13: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 00: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 02: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 01: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 12: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 11: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 06: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