[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes
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 SIGBREAK21 #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-12 07: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-12 00: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 23: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 21: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_
[ python-Bugs-1167262 ] Fails assertion in winsig.c under VC 8.0
Bugs item #1167262, was opened at 2005-03-21 04:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&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: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Timothy Fitz (timothyfitz) Assigned to: Nobody/Anonymous (nobody) Summary: Fails assertion in winsig.c under VC 8.0 Initial Comment: In 2.4 and current cvs initsignal in signalmodule.c calls PyOS_getsig which calls signal with an invalid signal number. Under VC 7.1 (and 7.0, and probably before) this would return SIG_ERR however under VC 8.0 (beta) this causes an assertion failure. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-10-12 09:54 Message: Logged In: YES user_id=21627 See #1311784 for more discussion of this problem. -- Comment By: Martin v. Löwis (loewis) Date: 2005-04-02 00:02 Message: Logged In: YES user_id=21627 C99 7.14.1.1/p8 specifies # If the request can be honored, the signal function # returns the value of func for the most recent successful # 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 it seems to me that VC8 is in error: the request cannot be "honored", so it should return SIG_ERR. Until/if VC8 is released with that bug, I would like to take no action here. When it is released, we still might consider to ignore it until say, 8.1 comes along and fixes the bug. -- Comment By: Michael Hudson (mwh) Date: 2005-03-27 22:59 Message: Logged In: YES user_id=6656 Ew. My first thought is, is that allowed by ANSI C? I'd guess it's undefined behaviour. It still seems excessively unfriendly -- have you reported this to MS? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes
Bugs item #1311784, was opened at 2005-10-03 14:18 Message generated for change (Comment added) made by loewis 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 SIGBREAK21 #define SIGABRT 22 A solution would be to restrict the loop in initsignal() to the above values under Windows. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-10-12 09: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 09: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-12 02: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-12 01: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 t
[ python-Bugs-1323810 ] MSI installer not working
Bugs item #1323810, was opened at 2005-10-11 14:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323810&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: Installation Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Eric Rucker (bhtooefr) Assigned to: Nobody/Anonymous (nobody) Summary: MSI installer not working Initial Comment: Attempted with Python 2.4.1 and 2.4.2 MSI files. When on the "Select Destination Directory" screen, clicking next does not work at all. Windows 2000 SP4, Windows ® Installer. V 3.01.4000. 1823. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-10-12 10:09 Message: Logged In: YES user_id=21627 Can you please elaborate what "does not work at all" means? Could you not move the mouse over the next button? Not press the left mouse button? Also, according to the log, a dialog was displayed "C:\Python24\ exists. Are you sure you want to overwrite existing files?" Did you see this dialog? Did it go away when you pressed Ok? Did you then select Next again? -- Comment By: Eric Rucker (bhtooefr) Date: 2005-10-12 03:25 Message: Logged In: YES user_id=844758 Here we go... I cancelled setup after a few minutes of waiting. So, that should show in the log somewhere. There's an in-flight version of the log, in there, as well. It's what I saw every time I checked the log while it was sitting doing nothing after I had clicked next. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-12 01:38 Message: Logged In: YES user_id=21627 Can you please generate a log file through msiexec /i python-2.4.1.msi /l*v python.log and attach a compressed version of the log file to this report? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323810&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1323810 ] MSI installer not working
Bugs item #1323810, was opened at 2005-10-11 08:24 Message generated for change (Comment added) made by bhtooefr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323810&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: Installation Group: Platform-specific Status: Open >Resolution: Works For Me >Priority: 1 Submitted By: Eric Rucker (bhtooefr) Assigned to: Nobody/Anonymous (nobody) Summary: MSI installer not working Initial Comment: Attempted with Python 2.4.1 and 2.4.2 MSI files. When on the "Select Destination Directory" screen, clicking next does not work at all. Windows 2000 SP4, Windows ® Installer. V 3.01.4000. 1823. -- >Comment By: Eric Rucker (bhtooefr) Date: 2005-10-12 05:28 Message: Logged In: YES user_id=844758 Umm... Well, what was happening was that when I clicked Next, nothing would happen, after that warning. I created the Python24 directory manually, trying to get it working. I now believe that it was some issue with that boot of my system. It worked no problem. *turns in geek card* -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-12 04:09 Message: Logged In: YES user_id=21627 Can you please elaborate what "does not work at all" means? Could you not move the mouse over the next button? Not press the left mouse button? Also, according to the log, a dialog was displayed "C:\Python24\ exists. Are you sure you want to overwrite existing files?" Did you see this dialog? Did it go away when you pressed Ok? Did you then select Next again? -- Comment By: Eric Rucker (bhtooefr) Date: 2005-10-11 21:25 Message: Logged In: YES user_id=844758 Here we go... I cancelled setup after a few minutes of waiting. So, that should show in the log somewhere. There's an in-flight version of the log, in there, as well. It's what I saw every time I checked the log while it was sitting doing nothing after I had clicked next. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-11 19:38 Message: Logged In: YES user_id=21627 Can you please generate a log file through msiexec /i python-2.4.1.msi /l*v python.log and attach a compressed version of the log file to this report? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323810&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1324799 ] Curses module doesn't install on Solaris 2.8
Bugs item #1324799, was opened at 2005-10-12 12:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: Curses module doesn't install on Solaris 2.8 Initial Comment: During installation, the following happens: building '_curses' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c -o build/temp.solaris-2.8- sun4u-2.4/_cursesmodule.o /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c: In function 'PyCursesWindow_GetStr': /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c:822: warning: implicit declaration of function 'mvwgetnstr' gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_cursesmodule.o -L/usr/gnu/lib -L/usr/local/lib -lcurses - ltermcap -o build/lib.solaris-2.8-sun4u-2.4/_curses.so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: ./python: fatal: relocation error: file build/lib.solaris-2.8-sun4u-2.4/_curses.so: symbol mvwgetnstr: referenced symbol not found building '_curses_panel' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_curses_panel.c -o build/temp.solaris-2.8- sun4u-2.4/_curses_panel.o gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_curses_panel.o -L/usr/gnu/lib -L/usr/local/lib -lpanel - lcurses -ltermcap -o build/lib.solaris-2.8-sun4u- 2.4/_curses_panel.so *** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1325071 ] "as" keyword sometimes highlighted in strings
Bugs item #1325071, was opened at 2005-10-12 19:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325071&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artur de Sousa Rocha (adsr) Assigned to: Nobody/Anonymous (nobody) Summary: "as" keyword sometimes highlighted in strings Initial Comment: IDLE sometimes highlights the "as" keyword inside strings. See the docstring to the get_redir() function in the attached script. IDLE 1.1.2, Python 2.4.2, but I've seen it in older versions too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325071&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1323810 ] MSI installer not working
Bugs item #1323810, was opened at 2005-10-11 14:24 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323810&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: Installation Group: Platform-specific >Status: Closed Resolution: Works For Me Priority: 1 Submitted By: Eric Rucker (bhtooefr) Assigned to: Nobody/Anonymous (nobody) Summary: MSI installer not working Initial Comment: Attempted with Python 2.4.1 and 2.4.2 MSI files. When on the "Select Destination Directory" screen, clicking next does not work at all. Windows 2000 SP4, Windows ® Installer. V 3.01.4000. 1823. -- Comment By: Eric Rucker (bhtooefr) Date: 2005-10-12 11:28 Message: Logged In: YES user_id=844758 Umm... Well, what was happening was that when I clicked Next, nothing would happen, after that warning. I created the Python24 directory manually, trying to get it working. I now believe that it was some issue with that boot of my system. It worked no problem. *turns in geek card* -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-12 10:09 Message: Logged In: YES user_id=21627 Can you please elaborate what "does not work at all" means? Could you not move the mouse over the next button? Not press the left mouse button? Also, according to the log, a dialog was displayed "C:\Python24\ exists. Are you sure you want to overwrite existing files?" Did you see this dialog? Did it go away when you pressed Ok? Did you then select Next again? -- Comment By: Eric Rucker (bhtooefr) Date: 2005-10-12 03:25 Message: Logged In: YES user_id=844758 Here we go... I cancelled setup after a few minutes of waiting. So, that should show in the log somewhere. There's an in-flight version of the log, in there, as well. It's what I saw every time I checked the log while it was sitting doing nothing after I had clicked next. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-12 01:38 Message: Logged In: YES user_id=21627 Can you please generate a log file through msiexec /i python-2.4.1.msi /l*v python.log and attach a compressed version of the log file to this report? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323810&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
