Bugs item #1311784, was opened at 2005-10-03 12:18 Message generated for change (Comment added) made by pete_icoserve 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: Peter Klotz (pete_icoserve) Date: 2005-10-11 13: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 20: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 07: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 09: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 08: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 19: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 18: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 13: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
