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