This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: python.exe 2.4.2 compiled with VS2005 crashes
Type: Stage:
Components: Windows Versions: Python 2.4
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: khepri, loewis, moese, mwh, nnorwitz, pete_icoserve
Priority: normal Keywords:

Created on 2005-10-03 12:18 by pete_icoserve, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (16)
msg26479 - (view) Author: Peter Klotz (pete_icoserve) Date: 2005-10-03 12:18
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.
msg26480 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-10-03 13:05
Logged In: YES 

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).
msg26481 - (view) Author: Peter Klotz (pete_icoserve) Date: 2005-10-03 18:10
Logged In: YES 

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.
msg26482 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2005-10-03 19:54
Logged In: YES 

Do you suggest this be special cased for VS2005 specifically
or Windows in general (ie, any version/compiler)?
msg26483 - (view) Author: Peter Klotz (pete_icoserve) Date: 2005-10-04 08:02
Logged In: YES 

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

Something like this comes to my mind:

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

This works for 32 and 64 bit platforms since _WIN32 is
defined in both cases.
msg26484 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-10-08 09:56
Logged In: YES 

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.
msg26485 - (view) Author: Peter Klotz (pete_icoserve) Date: 2005-10-10 07:05
Logged In: YES 

Do you really think ignoring/skipping VS2005 is a proper

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.
msg26486 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-10-10 20:13
Logged In: YES 

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 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.
msg26487 - (view) Author: Peter Klotz (pete_icoserve) Date: 2005-10-11 13:10
Logged In: YES 

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.
msg26488 - (view) Author: Moese (moese) Date: 2005-10-11 21:14
Logged In: YES 

I'm not so sure that setting an unsupporting signal and
expecting the operation to not crash/abort is valid ANSI-C:

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":

The list of supported signals:

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.
msg26489 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-10-11 23:36
Logged In: YES 

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.
msg26490 - (view) Author: Moese (moese) Date: 2005-10-12 00:17
Logged In: YES 

This has been reported before. Maybe these two bugs should
me merged somehow:

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).
msg26491 - (view) Author: Peter Klotz (pete_icoserve) Date: 2005-10-12 07:01
Logged In: YES 

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. 
msg26492 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-10-12 07:56
Logged In: YES 

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.
msg26493 - (view) Author: Kirjah Salys (khepri) Date: 2005-12-21 05:28
Logged In: YES 

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.
msg26494 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2005-12-21 05:43
Logged In: YES 

If you track down the references you will find the change
has been made to the CM repository in revision 41554.

See patch:

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?
Date User Action Args
2022-04-11 14:56:13adminsetgithub: 42442
2005-10-03 12:18:20pete_icoservecreate