[ python-Bugs-1463043 ] test_minidom.py fails for Python-2.4.3 on SUSE 9.3
Bugs item #1463043, was opened at 2006-04-02 16:03
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463043&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: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Martin v. Löwis (loewis)
Summary: test_minidom.py fails for Python-2.4.3 on SUSE 9.3
Initial Comment:
I built Python-2.4.3 from source on SUSE 9.3 and get
the following error for test_minidom.py
/usr/local/src/Python-2.4.3: ./python
Lib/test/test_minidom.py
Failed Test
Test Failed: testAltNewline
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 427, in
testAltNewline
confirm(domstr == str.replace("\n", "\r\n"))
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed testEncodings - encoding EURO SIGN
Test Failed: testEncodings
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 891, in
testEncodings
"testEncodings - encoding EURO SIGN")
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed After replaceChild()
Test Failed: testPatch1094164
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 1137, in
testPatch1094164
confirm(e.parentNode is elem, "After replaceChild()")
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Failed Test
Test Failed: testWriteXML
Traceback (most recent call last):
File "Lib/test/test_minidom.py", line 1384, in ?
func()
File "Lib/test/test_minidom.py", line 420, in
testWriteXML
confirm(str == domstr)
File "Lib/test/test_minidom.py", line 28, in confirm
raise Exception
Exception
Check for failures in these tests:
testAltNewline
testEncodings
testPatch1094164
testWriteXML
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-10 09:01
Message:
Logged In: YES
user_id=21627
It's no surprise that the error didn't occur in 2.5a1: the
PyXML-0.8.4 installation on rptownsend's machine was for
2.4; the 2.5 sandbox won't see 2.4's xmlplus. Even if PyXML
was installed on 2.5, the test suite would still refer to
xmlcore, thus bypassing PyXML.
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-07 12:07
Message:
Logged In: YES
user_id=200117
I added a few print statements to the tests - see attached
file py_243.txt for the results while running on Python-
2.4.3
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-06 14:31
Message:
Logged In: YES
user_id=200117
Interestingly, the error doesn't occur with Python-2.5a1
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-04 08:27
Message:
Logged In: YES
user_id=33168
Martin maintains PyXML AFAIK. Maybe he has some ideas. I
suspect this might be even worse in 2.5. Element Tree was
added and there was a name change. Some of those things
still need to be addressed.
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-03 15:37
Message:
Logged In: YES
user_id=200117
Hi Neal,
I've just built 2.4.3 on a Red Hat Enterpeise Edition WS
V4.2 machine and this gives the same error.
I've had this vague feeling that I've seen something like
this before, but couldn't find anything when I searched the
tracker...
I've now realised that the error is due to a conflict with
PyXML-0.8.4 which was already installed on both machines.
If I rename the ../site_packages/_xmlplus directory to a
different name then the error goes away (on the Red Hat
machine at least, the SUSE machine is at home).
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 07:37
Message:
Logged In: YES
user_id=33168
Thanks for letting us know about where the regression
occurred. Can you do a little more debugging to try to find
the cause and some ideas about how to fix it?
I'm not sure that any developer runs on a system that
exhibits this error. So it will probably be very difficult
for us to figure it out since we can't reproduce it.
--
Comment By: Richard Townsend (rptownsend)
Date: 2006-04-02 16:28
Message:
Logged In: YES
user_id=20
[ python-Feature Requests-1039857 ] win32 silent installation: allow MAINDIR on command line
Feature Requests item #1039857, was opened at 2004-10-04 12:23 Message generated for change (Settings changed) made by sigmud You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1039857&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matteo Gallivanoni (sigmud) Assigned to: Nobody/Anonymous (nobody) Summary: win32 silent installation: allow MAINDIR on command line Initial Comment: This request is related to my (false) "Bugs item #1038410" since it is by design and it won't be fixed I thought I could be suggested as a new feature. Request: Add a command line switch to be able to specify python install directory in silent installation mode in other word it should be something like this: Python-X.Y.Z.exe /s /d MAINDIR=C:\some_dir\python BTW: IIRC the windows wise installer configuration file is not provided into python cvs source tree so I can only suggest this google-groups thread as a hint: Newsgroups:wise.wise7.general Subject: "Passing the path name to a silent install. How?" Data:2000/01/17 -- Comment By: iga Seilnacht (zseil) Date: 2006-04-08 03:35 Message: Logged In: YES user_id=1326842 Starting with Python 2.4 it is possible to specify a TARGETDIR parameter to the msi installer. See http://www.python.org/download/releases/2.4/msi/ for more details. This feature request should be closed as fixed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1039857&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1036406 ] Tix.Grid widgets not implemented yet
Bugs item #1036406, was opened at 2004-09-28 20:35
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036406&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: Tkinter
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Martin v. Löwis (loewis)
Summary: Tix.Grid widgets not implemented yet
Initial Comment:
This code fails at the .pack method (.grid, .place too):
>>> import Tix
>>> r=Tix.Tk()
>>> g=Tix.Grid()
>>> g.pack()
Traceback (most recent call last):
File "", line 1, in ?
File "d:\PY.24\lib\lib-tk\Tkinter.py", line 1692, in
pack_configure
self.tk.call(
_tkinter.TclError: bad window path name ".8257088"
Tix Grids work though as shown here:
>>> r.tk.call('tixGrid', '.g1')
'.g1'
>>> r.tk.call('pack', '.g1')
''
>>> r.tk.call('.g1', 'set', '0', '0', '-text', 'hello!')
''
I intend to supply a patch, but I need to first
understand better how Tkinter works (and therefore
Tix.py); I create a bug so that anyone willing might help
provide Python users with an often requested widget.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-10 10:35
Message:
Logged In: YES
user_id=21627
This is fixed with patch #146.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1036406&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467619 ] Header.decode_header eats up spaces
Bugs item #1467619, was opened at 2006-04-10 12:33
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=1467619&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mathieu Goutelle (mgoutell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Header.decode_header eats up spaces
Initial Comment:
The Header.decode_header function eats up spaces in
non-encoded part of a header.
See the following source:
# -*- coding: iso-8859-1 -*-
from email.Header import Header, decode_header
h = Header('Essai ', None)
h.append('éè', 'iso-8859-1')
print h
print decode_header(h)
This prints:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test', None), ('\xe9\xe8', 'iso-8859-1')]
This should print:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test ', None), ('\xe9\xe8', 'iso-8859-1')]
^ This space disappears
This appears in Python 2.3 but the source code of the
function didn't change in 2.4 so the same problem
should still exist. Bug "[ 1372770 ] email.Header
should preserve original FWS" may be linked to that one
although I'm not sure this is exactly the same.
This patch (not extensively tested though) seems to
solve this problem:
--- /usr/lib/python2.3/email/Header.py 2005-09-05
00:20:03.0 +0200
+++ Header.py 2006-04-10 12:27:27.0 +0200
@@ -90,7 +90,7 @@
continue
parts = ecre.split(line)
while parts:
-unenc = parts.pop(0).strip()
+unenc = parts.pop(0).rstrip()
if unenc:
# Should we continue a long line?
if decoded and decoded[-1][1] is None:
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Matthias Klose (doko) Date: 2006-04-10 12:44 Message: Logged In: YES user_id=60903 Setup.local has the disadvantage that you have to edit the file. I updated the patch to only have an effect, if configure is passed --with-system-ffi. -- Comment By: Thomas Heller (theller) Date: 2006-04-07 19:49 Message: Logged In: YES user_id=11105 I'm astonished how flexible the build-system is :-), once you leave Windows. setup.py needs a change, though, so that the _ctypes/libffi configure script is not run when not needed. One possible advange of Modules/Setup.local is that one can define additional compilation flags for ctypes - for example, if ctypes would support it, to enable/disable certain features (varargs function calls, for example). -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-06 23:46 Message: Logged In: YES user_id=21627 If this configuration needs an operator decision, I think this decision is best made in Modules/Setup.local. Anybody who wants to use the local libffi installation can do so, by writing a Setup.local that lists the source files, and gives -lffi as a library option. Setup.dist could provide a commented version of such a configuration. setup.py *should* then skip over building _ctypes, as it should find out that _ctypes was already built through Makefile. -- Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? -- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for the different library names comes from the observation that libgcj is linked against libffi as a convenience library (for performance reasons?). These are checked first so that not another external dependency is introduced, if these libraries are available (not installed by a standard gcc installation). updating the code would at least make the library bu
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 14:00 Message: Logged In: YES user_id=21627 The code is fine, but it lacks documentation. There should be some way to learn about --with-system-ffi, preferably by either reading ./configure --help output, or reading README. -- Comment By: Matthias Klose (doko) Date: 2006-04-10 12:44 Message: Logged In: YES user_id=60903 Setup.local has the disadvantage that you have to edit the file. I updated the patch to only have an effect, if configure is passed --with-system-ffi. -- Comment By: Thomas Heller (theller) Date: 2006-04-07 19:49 Message: Logged In: YES user_id=11105 I'm astonished how flexible the build-system is :-), once you leave Windows. setup.py needs a change, though, so that the _ctypes/libffi configure script is not run when not needed. One possible advange of Modules/Setup.local is that one can define additional compilation flags for ctypes - for example, if ctypes would support it, to enable/disable certain features (varargs function calls, for example). -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-06 23:46 Message: Logged In: YES user_id=21627 If this configuration needs an operator decision, I think this decision is best made in Modules/Setup.local. Anybody who wants to use the local libffi installation can do so, by writing a Setup.local that lists the source files, and gives -lffi as a library option. Setup.dist could provide a commented version of such a configuration. setup.py *should* then skip over building _ctypes, as it should find out that _ctypes was already built through Makefile. -- Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? -- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check for LIBFFI_H really helps with this. yes, if gcc and ffi.h are installed from the same source / into the same path, then the check for include dirs and libraries are obsolete. the check for t
[ python-Bugs-837242 ] id() for large ptr should return a long
Bugs item #837242, was opened at 2003-11-06 16:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&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 Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Martin v. Löwis (loewis) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 14:27 Message: Logged In: YES user_id=21627 Right: about about this patch? -- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 22:52 Message: Logged In: YES user_id=849994 Ping! -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-13 18:24 Message: Logged In: YES user_id=1188172 You're making changes to PyLong_FromVoidPtr, doesn't PyLong_AsVoidPtr have to be changed too? -- Comment By: Martin v. Löwis (loewis) Date: 2006-01-11 23:39 Message: Logged In: YES user_id=21627 How about the attached patch? -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:21 Message: Logged In: YES user_id=1188172 Perhaps, for 2.5? -- Comment By: Martin v. Löwis (loewis) Date: 2003-11-06 21:54 Message: Logged In: YES user_id=21627 Would there anything be wrong with making that change right away? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-832799 ] Please link modules with shared lib
Bugs item #832799, was opened at 2003-10-30 02:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&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: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Martin v. Löwis (loewis) Summary: Please link modules with shared lib Initial Comment: We've been working with libraries that are loaded with dlopen (on Linux and Solaris, the land of ELF) and which, in turn, use the embedded python interpreter. Due to the behavior of the dynamic linker, this would work much better if modules were, by default, linked with -lpython2.3 instead of just left with hanging undefined symbols. Here's why. The main executable isn't linked with python, and none of it's direct dependents are. So, the python symbols aren't in the global namespace. The dlopened library is linked with python. However, when the dlopened library dlopens the modules, the linux linker is not clever enough to allow the second- order library to use symbols from its parent. (Solaris has such a feature, but not linux). So, one has to manually dlopen the python library with RTLD_GLOBAL to make it work. If each module had a NEED for the python lib (via -l at linktime), all this would just work. I've got some local patches to build_ext.py for this purpose, but it would be nice to have official support. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 14:40 Message: Logged In: YES user_id=21627 This was fixed with said patch in r45232. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 11:34 Message: Logged In: YES user_id=1188172 See patch #1429775. -- Comment By: benson margulies (benson_basis) Date: 2003-11-25 22:53 Message: Logged In: YES user_id=876734 I only see one possible issue with the patch. I exploited the existing BLDLIBRARY macro. It says '-L.' on linux. Which is fine for the initial 'make', but not too great when the Makefile gets copied to the install dir. The comments in the config dir leave me thinking that there would be a Makefile.pre in there, but there isn't. Just a Makefile. The RUNSHARED macro ends up set back to where I built it, not to where I installed it. If some process would fix RUNSHARED, it could also fix BLDSHARED. -- Comment By: benson margulies (benson_basis) Date: 2003-11-25 22:27 Message: Logged In: YES user_id=876734 I submitted a set of patches that work for the initial build. I think I'll need more for the tools that are used later, I'm moving on to that next. -- Comment By: Martin v. Löwis (loewis) Date: 2003-11-24 23:16 Message: Logged In: YES user_id=21627 1) Basically, you lose. If you don't want to build a module as a shared library, you can build it statically, through Modules/Setup. If you absolutely don't want to build a module at all, you edit setup.py, and modify disabled_module_list. If you don't want to edit disabled_module_list, you build the module, and delete it when done. 2) Using /usr/local/lib could be replaced, but I would consider this out of scope of this change. Feel free to submit a separate patch. Make sure that the alternative patch manages to pick up shared libraries in all cases where it finds them today. 3) 'cvs annotate' reveals that this was added in setup.py 1.100. 'cvs log' reveals that this was added in response to python.org/sf/589427, where the Debian maintainer complains that /usr/include is added to the list of -I options, even though the compiler already has /usr/include in its search list. -- Comment By: benson margulies (benson_basis) Date: 2003-11-23 21:44 Message: Logged In: YES user_id=876734 I'm running into issues trying to come up with a clean version of this. I'd like to know what you think of some of these before I try to port what I've got into 2.4 and come up with patches. 1) setup.py seems to have no way to be selective about which modules to build. What if I don't want to try (and then fail make install) to build, for example, ssl? 2) setup.py makes assumptions about pathnames. It always puts /usr/local/lib into the build path. On a 64-bit solaris or HP system, this can lead to a mess, if the 64 bit libraries are somewhere else. 3) There is an existing provision to add additional libs to the build in setup.py, bu
[ python-Bugs-837242 ] id() for large ptr should return a long
Bugs item #837242, was opened at 2003-11-06 15:11 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&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 Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Nobody/Anonymous (nobody) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-10 12:52 Message: Logged In: YES user_id=849994 Looks fine from my POV. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 12:27 Message: Logged In: YES user_id=21627 Right: about about this patch? -- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 21:52 Message: Logged In: YES user_id=849994 Ping! -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-13 17:24 Message: Logged In: YES user_id=1188172 You're making changes to PyLong_FromVoidPtr, doesn't PyLong_AsVoidPtr have to be changed too? -- Comment By: Martin v. Löwis (loewis) Date: 2006-01-11 22:39 Message: Logged In: YES user_id=21627 How about the attached patch? -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 22:21 Message: Logged In: YES user_id=1188172 Perhaps, for 2.5? -- Comment By: Martin v. Löwis (loewis) Date: 2003-11-06 20:54 Message: Logged In: YES user_id=21627 Would there anything be wrong with making that change right away? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467619 ] Header.decode_header eats up spaces
Bugs item #1467619, was opened at 2006-04-10 10:33
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mathieu Goutelle (mgoutell)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Header.decode_header eats up spaces
Initial Comment:
The Header.decode_header function eats up spaces in
non-encoded part of a header.
See the following source:
# -*- coding: iso-8859-1 -*-
from email.Header import Header, decode_header
h = Header('Essai ', None)
h.append('éè', 'iso-8859-1')
print h
print decode_header(h)
This prints:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test', None), ('\xe9\xe8', 'iso-8859-1')]
This should print:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test ', None), ('\xe9\xe8', 'iso-8859-1')]
^ This space disappears
This appears in Python 2.3 but the source code of the
function didn't change in 2.4 so the same problem
should still exist. Bug "[ 1372770 ] email.Header
should preserve original FWS" may be linked to that one
although I'm not sure this is exactly the same.
This patch (not extensively tested though) seems to
solve this problem:
--- /usr/lib/python2.3/email/Header.py 2005-09-05
00:20:03.0 +0200
+++ Header.py 2006-04-10 12:27:27.0 +0200
@@ -90,7 +90,7 @@
continue
parts = ecre.split(line)
while parts:
-unenc = parts.pop(0).strip()
+unenc = parts.pop(0).rstrip()
if unenc:
# Should we continue a long line?
if decoded and decoded[-1][1] is None:
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1465406 ] Allowing the definition of constants
Feature Requests item #1465406, was opened at 2006-04-06 01:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&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: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Wilson (ciw42) Assigned to: Nobody/Anonymous (nobody) Summary: Allowing the definition of constants Initial Comment: One of the current optimizations due in v2.5 includes constant folding of expressions, which as it stands serves as a way of somply getting rid of a redundant arithmetic operations and the like. In practice, it's rare a developer would leave an expression such as "2+3" sat in his/her code, but by allowing the declaration of constants within a script, it could make this new feature *much* more useful. As an example, in a recent script I had the following at the top, outside the main loop: SCREEN_WIDTH=640 SCREEN_HEIGHT=480 SCREEN_RATIO=SCREEN_WIDTH/SCREEN_HEIGHT As SCREEN_RATIO is used a number of times during my main loop, it makes sense to pre-calculate it to avoid the extra processing, but if the compiler were aware that SCREEN_WIDTH and SCREEN_HEIGHT were constants, it could optimise out the calculation and I could include the calculation in-place. I frequently make use of "constants" to make my code more readable, and wonder whether there is any performance penalty or lack of optimisation going on due to them in fact being regular variables? -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 15:55 Message: Logged In: YES user_id=21627 The problem is that declaring the value assignment const doesn't help. Consider this: from math import pi def area(r): return r*r*pi pi = 4 print area(10) So even though math.pi might be declared as a constant, hard-coding its value into the function area would break this program - the value of the variable pi might change not change inside math, but it might change where it is imported. -- Comment By: Chris Wilson (ciw42) Date: 2006-04-06 23:59 Message: Logged In: YES user_id=1018283 I've re-opened this, as I don't feel it would be difficult to implement or require any fundamental changes to the parser or runtime. In fact, it would be very easy, and potentially very useful beyond the scope of my initial suggestion. Appologies to rhettinger if this seems rude, but I would ask that you give the following some consideration. The addition of a "const" or similar compiler directive would allow the compiler to simply do an on-the-fly substitution for the specified value/string etc. There would be no code analysis required, and adding this type of functionality would carry no real overheads or further complicate the compilation process. There would be no changes required within the runtime. Once substituted, the already incorporated compiler constant folding features would then come into play. I suppose, that what I'm suggesting is effectively a basic pre-compiler macro feature. This in itself may prove useful in many other situations. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-06 01:57 Message: Logged In: YES user_id=80475 Python is too dynamic for this kind of optimization to be done automatically. If those "constants" are defined at the module level, they can be changed by code outside the module. Even within the module, it would take a thorough analysis of the code to determine that nothing was trying to alter the value of the global variable. If the "constant" is defined inside a function, it is still a local variable subject to change by later lines in function. Your best bet is to use the bind_consts recipe at ASPN. It will automatically turn some global references into locals: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277 940 It may be possible to adapt the recipe to go an additional step and fold the globals "constants". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1425256 ] Support for MSVC 7 and MSVC8 in msvccompiler
Feature Requests item #1425256, was opened at 2006-02-06 15:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1425256&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: Distutils Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: dlm (davidlukas) Assigned to: Nobody/Anonymous (nobody) Summary: Support for MSVC 7 and MSVC8 in msvccompiler Initial Comment: Hi, I tried to build the "ctypes-0.9.6" packages from source with Microsoft Visual Studio 8 (2005). I realized that in module "distutils" of Python 2.4.1 both VC7 and VC8 compilers are not supported at all (only VC6). I took a glance at distutils at Python 2.4.2 but also there no VC8 is supported. I tried to figure out where I should extend the compiler detection, but the whole file "msvccompiler.py" seems to me like a big hack. I've wrote some code, to get VC8 working on my machine (set right pathes to Include- and Lib-Directories and to the binaries), but I don't think it's redistributable. What do you think of detecting the right MS-Compiler like this: def detectCompiler() : detectVC6() detectVC7() detectVC8() and hiding the code for each particular version of VC in a separate function. I don't think MS is following a streight upwards compatibility strategy. Also ther should be a way, to select on compiler, when multiple compilers are detected. I saw the --compiler=whatever switch, but did not found any documentation on it. I've got both versions (VC7 and VC8) installed on my machine. So I can try out different detection routines if you want. Another problem with VC8 is cross-compiling, since ther e are different library-directories for different platforms (AMD64, x86, Itanium, Win32, ...). Also here I see big deficits in the distutil-module at the moment. Best regards David -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 15:59 Message: Logged In: YES user_id=21627 Why do you think only VC6 is supported in distutils? It works just fine with VC7.1 (Visual Studio .NET 2003). Don't try to build Python extension modules with VS 2005 (aka VC8), unless you know precisely what you are doing: by doing so, you link different versions of msvcrt; this might cause crashes. In general, you must use the same C compiler that Python was built with. There is not much we can do about this (it's a Microsoft limitation), so I'm rejecting the request. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1425256&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-960454 ] old/new class documentation
Feature Requests item #960454, was opened at 2004-05-26 00:33 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=960454&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: old/new class documentation Initial Comment: The distributed documentation refers to old and new-style classes, but they do not appear in the index, and the difference is not explained. (Users who ask are referred to documentation on www.python.org, which is not currently shipped with the default distrubution.) As best I understand it, the only differences are: (1) New-style classes inherit from object. Because of this inheritance, new-style classes have a few extra capabilities, such as descriptors and super. (2) Method Resolution Order can be different in cases of multiple inheritance. (3) New style classes take precedence over old-style classes when doing rich comparison. (4) If rich comparison fails, numeric coercion will be attempted if -- and only if -- at least one of the objects is an old-style class. -- Comment By: iga Seilnacht (zseil) Date: 2006-04-10 16:07 Message: Logged In: YES user_id=1326842 This seems like a duplicate of bug #960340, which was closed when section New-style and classic classes was added to the Python Reference Manual (see http://docs.python.org/dev/ref/node33.html). -- Comment By: Edward Diener (eldiener) Date: 2004-08-02 01:53 Message: Logged In: YES user_id=490593 New style classes, with all their new attributes, member functions, static methods, and class methods, need to be documented in the official Python distribution. Included in this is the explanation of metaclasses and how to use them. Essentially Guido's paper on new style classes, reworked to fit within the existing documentation framework, should be added to the official documantation.. -- Comment By: Jim Jewett (jimjjewett) Date: 2004-05-26 17:21 Message: Logged In: YES user_id=764593 Found a new difference -- you can't assign to the __bases__ or __name__ of a new-style class, and you can't usually assign to it's __class__. -- Comment By: Jim Jewett (jimjjewett) Date: 2004-05-26 16:05 Message: Logged In: YES user_id=764593 Given that the differences are almost -- but not entirely -- extra options for new-style classes, the language lawyer section on classes (ref/7.6) might be a good location. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=960454&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460493 ] Why not drop the _active list?
Bugs item #1460493, was opened at 2006-03-29 07:16 Message generated for change (Comment added) made by atila-cheops You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: HVB bei TUP (hvb_tup) Assigned to: Nobody/Anonymous (nobody) Summary: Why not drop the _active list? Initial Comment: I am using a modified version of subprocess.py, where I have removed the _active list and all references to it. I have tested it (under Windows 2000) and there were no errors. So what is the reason for managing the _active list at all? Why not drop it? -- Comment By: cheops (atila-cheops) Date: 2006-04-10 14:55 Message: Logged In: YES user_id=1276121 see patch #1467770 -- Comment By: cheops (atila-cheops) Date: 2006-04-05 08:27 Message: Logged In: YES user_id=1276121 the implementation in 2.5 of popen2 seems good if you or astrand could patch subprocess.py accordingly, that would be great. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-30 16:31 Message: Logged In: YES user_id=21627 attila-cheops, please read the 2.5 version of popen2. popen2 now only adds processes to _active in __del__, not in __init__, so the problem with the application still wanting to wait/poll is solved. Multiple threads simultaneously isn't a problem, since it is (or should be) harmless to invoke poll on a process that has already been waited for. For only one of the poll calls, the wait will actually succeed, and that should be the one that removes it from the _active list. The same strategy should be applied to subprocess. -- Comment By: cheops (atila-cheops) Date: 2006-03-30 08:17 Message: Logged In: YES user_id=1276121 also #1214859 is interesting, has a patch -- Comment By: cheops (atila-cheops) Date: 2006-03-30 08:06 Message: Logged In: YES user_id=1276121 the same problem probably exists in popen2.py there _active is also used so if something is fixed in subprocess.py, it should probably also be fixed in popen2.py -- Comment By: cheops (atila-cheops) Date: 2006-03-30 08:04 Message: Logged In: YES user_id=1276121 what happens if you are doing a _cleanup (iterating over a copy of _active) in multiple threads? can it not happen then that you clean up a process 2 times? thread 1 starts a _cleanup: makes a copy of _active[:] and starts polling thread 2 starts a _cleanup: makes a copy of _active[:] and starts polling thread 1 encounters a finished process and removes it from _active[] thread 2 does not know the process is removed, finds the same process finished and tries to remove it from _active but this fails, because thread 1 removed it already so the action of cleaning up should maybe be serialized if 1 thread is doing it, the other one should block everyone who needs this can of course patch the subprocess.py file, but shouldn't this be fixed in the library? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-30 07:43 Message: Logged In: YES user_id=33168 If you always called wait() the _active list isn't beneficial to you. However, many people do not call wait and the _active list provides a mechanism to cleanup zombied children. This is important for many users. If you need thread safely, you can handle the locking yourself before calling poll()/wait(). -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-29 20:41 Message: Logged In: YES user_id=21627 The purpose of the _active list is to wait(2) for open processes. It needs to stay. -- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 13:59 Message: Logged In: YES user_id=1488657 I agree. The use of _active makes subprocess.py thread-UNsafe. See also: Bug #1199282 In order to have a thread-safe subprocess.py, I commented out the call to _cleanup() in Popen.__init__(). As a side effect, _active becomes useless. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/
[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 14:27 Message generated for change (Comment added) made by atila-cheops You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&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: Closed Resolution: Accepted Priority: 5 Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- Comment By: cheops (atila-cheops) Date: 2006-04-10 14:55 Message: Logged In: YES user_id=1276121 see patch # 1467770 for subprocess.py library module -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 08:16 Message: Logged In: YES user_id=21627 Committed as 43286. I also added .cmd to Popen4. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 07:56 Message: Logged In: YES user_id=33168 It makes sense to remove from _active on ECHILD. I wondered the same thing about waitpid(), but left it as it was. I don't believe it's possible for waitpid to return any pid other than what you ask for unless the O/S is very, very broken. This patch is fine with me, feel free to check it in. BTW, nice comments and precondition checks in the test. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 07:40 Message: Logged In: YES user_id=21627 This looks all fine. As a further issue, I think _cleanup should also clean processes which already have been waited on. So if waitpid gives ECHILD (in _cleanup), I think the object should get removed from _active - otherwise, it would stay there forever. Of course, care is then need to avoid __del__ adding it back to _active. Putting these all together, I propose v3 of the patch. Another aspect that puzzles me is the repeated test that waitpid() really returns the pid you asked for. How could it not? If it fails, you get an os.error. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 05:17 Message: Logged In: YES user_id=33168 I agree with your comment about setting self.sts to 0. That was the problem I alluded to on python-dev. Although I dislike __del__, this does seem like an appropriate place to do the modification of _active. Note that currently all os.error's are swallowed in poll(). I'm not sure if that was the best idea, but that's the current interface. wait() does *not* catch any exceptions. I wasn't really sure what to do about threads. The threads could always manage their calls into a popen object like you propose (don't try to handle simultaneous calls to poll and wait). Another question I had was if popen should be deprecated in favor of subprocess? I've attached a patch which I think implements your suggestion. It also seems to fix all the problems. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 00:37 Message: Logged In: YES user_id=21627 I don't understand why you are setting self.sts to 0 if wait fails: most likely, there was a simultaneous call to .poll, which should have set self.sts to the real return value. So we should return that instead. I think the whole issue can be avoid if we use resurrection
[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active
Bugs item #1199282, was opened at 2005-05-10 18:24
Message generated for change (Comment added) made by atila-cheops
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&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: cheops (atila-cheops)
Assigned to: Peter Ã
strand (astrand)
Summary: subprocess _active.remove(self) self not in list _active
Initial Comment:
I start a subprocess in a seperate thread (25 concurrent
threads)
in some of the threads the following error occurs
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "upgrade.py", line 45, in run
returncode = p.wait()
File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
this is the code that starts the subprocess and where I
wait for the result
p = subprocess.Popen('command', \
stdin=None,
stdout=subprocess.PIPE, \
stderr=subprocess.STDOUT,
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()
--
>Comment By: cheops (atila-cheops)
Date: 2006-04-10 14:57
Message:
Logged In: YES
user_id=1276121
see patch #1467770
--
Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 13:50
Message:
Logged In: YES
user_id=1488657
> Simply list operations such as remove() and append() are
> thread safe,
OK, my apologies... I did not know.
I did some more tests. On Linux, I found lots of:
File "./subprocess.py", line 428, in call
return Popen(*args, **kwargs).wait()
File "./subprocess.py", line 1023, in wait
pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes
The try...except solution does not handle this (since we are
in the "posix" section).
In my opinion, the call to _cleanup() in Popen.__init__() is
useless (it just checks if older processes have stopped when
a new one is started. I cannot see why it could be
mandatory) and it is the root of this bug.
I commented it out (line 506) and retried my tests on Linux
& Windows plateforms: I had no exception at all.
--
Comment By: Peter Ã
strand (astrand)
Date: 2006-03-29 05:11
Message:
Logged In: YES
user_id=344921
>I think accesses to _active should be serialized in a
>thread-safe way. _active could be a Queue (from the Queue
>module) for example
Simply list operations such as remove() and append() are
thread safe, so there should be no need for a Queue. Also, a
Queue cannot be used since the subprocess module needs to be
compatible with Python 2.2.
--
Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-28 23:17
Message:
Logged In: YES
user_id=1488657
I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.
It has never appened (yet) on a Linux plateform.
I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-25 08:10
Message:
Logged In: YES
user_id=1434251
Wouldn't it be best to completely remove any references
to "_active" and "_cleanup"?
--
Comment By: cheops (atila-cheops)
Date: 2006-01-25 07:08
Message:
Logged In: YES
user_id=1276121
As suggested by astrand
adding a try ... except clause in the file subprocess.py did
the job
I had to add that try ... except clause in 2 places
if you look in the file there are 2 instances were
list.remove(x) occurs unprotected.
try:
list.remove(x)
except:
pass
I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three
needed the patch.
Hope this helps.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 16:34
Message:
Logged In: YES
user_id=1434251
BTW: In my case, I call python.exe from a Windows service.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 16:30
Message:
Logged In: YES
user_id=1434251
I have a similar problem.
Python 2.4.1 under MS Windows 2003,
Multi-Threaded application (about concurrent 10 threads).
In my case the same error occurs during _cleanup called
from __init__ :
File "E:\lisa_ins\ewu\coop\reporti
[ python-Bugs-1460493 ] Why not drop the _active list?
Bugs item #1460493, was opened at 2006-03-29 09:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&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: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: HVB bei TUP (hvb_tup) Assigned to: Nobody/Anonymous (nobody) Summary: Why not drop the _active list? Initial Comment: I am using a modified version of subprocess.py, where I have removed the _active list and all references to it. I have tested it (under Windows 2000) and there were no errors. So what is the reason for managing the _active list at all? Why not drop it? -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 17:58 Message: Logged In: YES user_id=21627 This was fixed with said patch. -- Comment By: cheops (atila-cheops) Date: 2006-04-10 16:55 Message: Logged In: YES user_id=1276121 see patch #1467770 -- Comment By: cheops (atila-cheops) Date: 2006-04-05 10:27 Message: Logged In: YES user_id=1276121 the implementation in 2.5 of popen2 seems good if you or astrand could patch subprocess.py accordingly, that would be great. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-30 18:31 Message: Logged In: YES user_id=21627 attila-cheops, please read the 2.5 version of popen2. popen2 now only adds processes to _active in __del__, not in __init__, so the problem with the application still wanting to wait/poll is solved. Multiple threads simultaneously isn't a problem, since it is (or should be) harmless to invoke poll on a process that has already been waited for. For only one of the poll calls, the wait will actually succeed, and that should be the one that removes it from the _active list. The same strategy should be applied to subprocess. -- Comment By: cheops (atila-cheops) Date: 2006-03-30 10:17 Message: Logged In: YES user_id=1276121 also #1214859 is interesting, has a patch -- Comment By: cheops (atila-cheops) Date: 2006-03-30 10:06 Message: Logged In: YES user_id=1276121 the same problem probably exists in popen2.py there _active is also used so if something is fixed in subprocess.py, it should probably also be fixed in popen2.py -- Comment By: cheops (atila-cheops) Date: 2006-03-30 10:04 Message: Logged In: YES user_id=1276121 what happens if you are doing a _cleanup (iterating over a copy of _active) in multiple threads? can it not happen then that you clean up a process 2 times? thread 1 starts a _cleanup: makes a copy of _active[:] and starts polling thread 2 starts a _cleanup: makes a copy of _active[:] and starts polling thread 1 encounters a finished process and removes it from _active[] thread 2 does not know the process is removed, finds the same process finished and tries to remove it from _active but this fails, because thread 1 removed it already so the action of cleaning up should maybe be serialized if 1 thread is doing it, the other one should block everyone who needs this can of course patch the subprocess.py file, but shouldn't this be fixed in the library? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-30 09:43 Message: Logged In: YES user_id=33168 If you always called wait() the _active list isn't beneficial to you. However, many people do not call wait and the _active list provides a mechanism to cleanup zombied children. This is important for many users. If you need thread safely, you can handle the locking yourself before calling poll()/wait(). -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-29 22:41 Message: Logged In: YES user_id=21627 The purpose of the _active list is to wait(2) for open processes. It needs to stay. -- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 15:59 Message: Logged In: YES user_id=1488657 I agree. The use of _active makes subprocess.py thread-UNsafe. See also: Bug #1199282 In order to have a thread-safe subprocess.py, I commented out the call to _cleanup() in Popen.__init__(). As a side effect, _active becomes useless. -- You can respond by vis
[ python-Bugs-1214859 ] subprocess auto-reaps children
Bugs item #1214859, was opened at 2005-06-04 18:42 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214859&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: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mattias Engdegård (yorick) Assigned to: Peter à strand (astrand) Summary: subprocess auto-reaps children Initial Comment: The subprocess module automatically reaps child processes, by maintaining a list of instances which is traversed each time a new Popen instance is created. Apparently this was originally intended to avoid large number of zombie processes to accrete in the system if the programmer is lazy and does not wait for them properly, but it can cause problems when the programmer wants greater control. In particular, it's not possible to use the pid from a subprocess.Popen instance, since it may already have disappeared. For instance, it makes it difficult to use os.wait() to wait for several child processes at the same time. The solution is simple: Add an option that disables the auto-reaper for a Popen instance. This makes everyone happy: existing code is unaffected, the programmer who wants to control her processes herself is allowed to do that, and the documentation is improved to help avoiding a nasty bug. A patch was posted to the patch tracker as number 1187312. I suggest it for inclusion into the next release. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 18:04 Message: Logged In: YES user_id=21627 Thanks for the report. This is now fixed in r45234. -- Comment By: Andrew Waters (awaters) Date: 2006-02-02 09:37 Message: Logged In: YES user_id=1418249 May want to add a lock in order that auto reaping can happen in addition to the use of waitpid. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1214859&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467929 ] %-formatting and dicts
Bugs item #1467929, was opened at 2006-04-10 21:39
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=1467929&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 Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: %-formatting and dicts
Initial Comment:
This looks like a bug in the way the %-formatting code
works or is it a feature ?
>>> '%s %(a)s' % {'a': 'xyz'}
"{'a': 'xyz'} xyz"
>>> u'%s %(a)s' % {'a': 'xyz'}
u"{'a': 'xyz'} xyz"
Note that both strings and Unicode are affected.
Python 2.3 and 2.4 also show this behavior.
I would have expected an exception or the %-formatter
simply ignoring the first %s.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465838 ] HP-UX11i: illegal combination of compilation and link flags
Bugs item #1465838, was opened at 2006-04-06 09:53 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i: illegal combination of compilation and link flags Initial Comment: According to Boris Gubenko from the HP-UX compiler development team, it is illegal to link with -lpthread if the sources are not compiled with -mt. However, this is exactly what happens during Python installation, e.g.: cc -Ae -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Python/compile.o Python/compile.c ... aCC -Wl,-E -Wl,+s -o python \ Modules/python.o \ libpython2.5.a -lnsl -lrt -ldld -ldl -lpthread -lm This illegal combination of compilation and link flags eventually results in obscure runtime failures (segfault, abort) while running Boost.Python C++ extensions. These failures go away if Python is installed with, e.g.: env CXX="aCC -mt" BASECFLAGS="-mt" ./configure --without-gcc I suggest changing the configure/make files to always include "-mt" if threading is enabled. BTW: The same issue already exists for Python 2.4. Cheers, Ralf -- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-04-10 12:44 Message: Logged In: YES user_id=71407 > Hm. We need to detect if we're on HP/UX, of course. Is > this option for all versions? I guess so since it seems very fundamental, but I am not sure. I alerted Boris Gubenko to this problem report. I hope he will help out. > And I assume it's only for the HP compiler, not gcc? I don't know. I imagine gcc has similar issues since it does link with the same -lpthread eventually. Note that the machine I used is publically accessible: http://www.testdrive.hp.com/ After you register on the web: telnet td176.testdrive.hp.com gcc 3.4.3 is installed. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 08:30 Message: Logged In: YES user_id=29957 Hm. We need to detect if we're on HP/UX, of course. Is this option for all versions? And I assume it's only for the HP compiler, not gcc? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467952 ] os.listdir on Linux returns empty list on some errors
Bugs item #1467952, was opened at 2006-04-10 15:12 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=1467952&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gary Stiehr (gstiehr) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir on Linux returns empty list on some errors Initial Comment: os.listdir() (defined in the posix_listdir() function on line 1449 of Modules/posixmodule.c in the Python-2.4.3 source distribution) does not check for an error condition when it calls the readdir() system call on line 1665 of posixmodule.c. According to the readdir(3) man page included the Scientific Linux 4.2 (based off of Red Hat Enterprise Linux 4 sources): The readdir() function returns a pointer to a dirent structure, or NULL if an error occurs or end-of-file is reached. It seems that the posix_listdir() function assumes that NULL can only mean end-of-file. Therefore, in the situation where readdir() returns NULL due to some error, such as an I/O Error, posix_listdir() ends the while loop started at line 1665 and goes to the closedir() call at line 1702. This results in an os.listdir() call returning an empty list (as if the directory had no contents) instead of raising an exception. This error was noticed because we performed an ls in a particular directory and it returned with an I/O error. I was then writing a python script to monitor for this condition when I found that the os.listdir() in this directory returned an empty list instead of an I/O error. This behavior was noticed using Python 2.3.4; I looked at the latest (as of 2006-04-07) stable release source (Python 2.4.3) to investigate and to provide the details in this bug report. I also took a quick look at the most recent 2.5.x code and although the posix_listdir function has changed, it still appears as if it would return an empty list if the readdir() call returns NULL. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467952&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-837242 ] id() for large ptr should return a long
Bugs item #837242, was opened at 2003-11-06 16:11 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&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 Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 22:28 Message: Logged In: YES user_id=21627 Committed as r45239. -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-10 14:52 Message: Logged In: YES user_id=849994 Looks fine from my POV. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 14:27 Message: Logged In: YES user_id=21627 Right: about about this patch? -- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 22:52 Message: Logged In: YES user_id=849994 Ping! -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-13 18:24 Message: Logged In: YES user_id=1188172 You're making changes to PyLong_FromVoidPtr, doesn't PyLong_AsVoidPtr have to be changed too? -- Comment By: Martin v. Löwis (loewis) Date: 2006-01-11 23:39 Message: Logged In: YES user_id=21627 How about the attached patch? -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 23:21 Message: Logged In: YES user_id=1188172 Perhaps, for 2.5? -- Comment By: Martin v. Löwis (loewis) Date: 2003-11-06 21:54 Message: Logged In: YES user_id=21627 Would there anything be wrong with making that change right away? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&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: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Matthias Klose (doko) Date: 2006-04-10 22:45 Message: Logged In: YES user_id=60903 documentation added. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 14:00 Message: Logged In: YES user_id=21627 The code is fine, but it lacks documentation. There should be some way to learn about --with-system-ffi, preferably by either reading ./configure --help output, or reading README. -- Comment By: Matthias Klose (doko) Date: 2006-04-10 12:44 Message: Logged In: YES user_id=60903 Setup.local has the disadvantage that you have to edit the file. I updated the patch to only have an effect, if configure is passed --with-system-ffi. -- Comment By: Thomas Heller (theller) Date: 2006-04-07 19:49 Message: Logged In: YES user_id=11105 I'm astonished how flexible the build-system is :-), once you leave Windows. setup.py needs a change, though, so that the _ctypes/libffi configure script is not run when not needed. One possible advange of Modules/Setup.local is that one can define additional compilation flags for ctypes - for example, if ctypes would support it, to enable/disable certain features (varargs function calls, for example). -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-06 23:46 Message: Logged In: YES user_id=21627 If this configuration needs an operator decision, I think this decision is best made in Modules/Setup.local. Anybody who wants to use the local libffi installation can do so, by writing a Setup.local that lists the source files, and gives -lffi as a library option. Setup.dist could provide a commented version of such a configuration. setup.py *should* then skip over building _ctypes, as it should find out that _ctypes was already built through Makefile. -- Comment By: Thomas Heller (theller) Date: 2006-04-06 22:02 Message: Logged In: YES user_id=11105 I do not really know. Maybe using distutils.sysconfig.get_config_var() ? A pragmatic approach would be to parse pyconfig.h itself in the setup script. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 21:45 Message: Logged In: YES user_id=60903 maybe a configure switch --with-system-ffi could do it? How to pass this to the setup.py file? -- Comment By: Thomas Heller (theller) Date: 2006-04-06 21:17 Message: Logged In: YES user_id=11105 I tried your patch on an AMD64 ubuntu 5.10, after I installed the 4.0.1-4ubuntu9 libffi package. It crashes in ctypes/test/test_python_api.py, test_PyOS_snprintf. IIRC, libffi did not support varargs functions, but Andreas Degert added support for them (for x86_64), and it works fine. Ok, new features in libffi might not be the norm, but I see no way how I can check whether a system-installed libffi supports this feature or not. Do *you* see a solution for that? For the actual changes to setup.py, if the patch really is a good idea: Since I don't even know what a convience library is I'll trust you fully that your patch does the right thing. -- Comment By: Matthias Klose (doko) Date: 2006-04-06 15:12 Message: Logged In: YES user_id=60903 > do any of the buildbot slaves have a system libffi > installed? the Debian and Ubuntu bots have libffi from gcc-4.1 installed. I think in the past, there was a complaint about a conflicting ffi.h, or maybe was this ffitarget.h? not sure if the check
[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 10:47
Message generated for change (Comment added) made by atler_
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&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: nomind (vnainar)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses library in python 2.4.3 broken
Initial Comment:
My python programs using curses library do not work
with version 2.4.3.Even the 'ncurses.py ' demo program
in the Demo/curses directory does not work correctly.
The problem seems to be in the 'panels' library
--
Comment By: Jan Palus (atler_)
Date: 2006-04-10 23:24
Message:
Logged In: YES
user_id=1497957
loewis: removing lines refering to ncursesw solves the
problem. ncurses.py runs fine as well as other programs.
What is actual problem then? Something with ncursesw or
with python?
Anyway, Thanks for your help.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 22:58
Message:
Logged In: YES
user_id=21627
atler_: around line 427, you find
if self.compiler.find_library_file(lib_dirs,
'ncursesw'):
readline_libs.append('ncursesw')
elif self.compiler.find_library_file(lib_dirs,
'ncurses'):
Replace that with
if self.compiler.find_library_file(lib_dirs,
'ncurses'):
(i.e. dropping the ncursesw part), and rebuild.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 15:48
Message:
Logged In: YES
user_id=1497957
More complete backtrace, I hope it will help:
http://pastebin.com/649445
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 14:14
Message:
Logged In: YES
user_id=29957
The buildbot boxes don't show this problem.
You might need to rebuild a Python with -g and unstripped to
get a useful backtrace.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 12:51
Message:
Logged In: YES
user_id=1497957
$ ldd /usr/lib/python2.4/lib-dynload/_curses.so
libncursesw.so.5 => /usr/lib/libncursesw.so.5
(0x7004c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7008)
libc.so.6 => /lib/libc.so.6 (0x700e4000)
libdl.so.2 => /lib/libdl.so.2 (0x70228000)
libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000)
/lib/ld-linux.so.2 (0x7000)
...
Program received signal SIGSEGV, Segmentation fault.
0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
gdb) bt
#0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
#1 0x706254b8 in ?? () from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
#2 0x706254b8 in ?? () from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
Previous frame identical to this frame (corrupt stack?)
It seems that only programs using panel library cause
segfaults (all other demos run fine except ncurses.py),
sorry for a mistake in a last post.
loewis: I'm not sure I understand second point. What excatly
should be changed in setup.py?
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-09 12:46
Message:
Logged In: YES
user_id=1126061
Cannot reproduce on Gentoo. All the files in the Demo/curses
directory run fine.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 12:29
Message:
Logged In: YES
user_id=21627
I can't reproduce any of this on Debian;
Demo/curses/ncurses.py runs fine. Can you please
1. run ldd on _curses.so, and report the output, and
2. edit setup.py, removing the lines that deal with ncursesw,
3. atler_: produce a gdb backtrace on the time of the crash,
4: vnainar: please report what you mean by "does not work".
Does it erase your hard disk? turn off the machine? Paint
things blue instead of red?
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 12:06
Message:
Logged In: YES
user_id=1497957
I confirm the problem. Every program using curses library
segfaults and there's only one error before it happens:
...
import curses # directory /usr/share/python2.4/curses
import curses # precompiled from
/usr/share/python2.4/curses/__init__.pyc
dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2);
import _curses # dynamically loaded from
/usr/lib/python2
[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 10:47
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&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: nomind (vnainar)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses library in python 2.4.3 broken
Initial Comment:
My python programs using curses library do not work
with version 2.4.3.Even the 'ncurses.py ' demo program
in the Demo/curses directory does not work correctly.
The problem seems to be in the 'panels' library
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 00:28
Message:
Logged In: YES
user_id=21627
That's hard to tell. Somebody would have to debug ncurses to
find out why it crashes. Notice that it crashes only on some
installations, so it is likely rather a problem with your
ncurses installation, than with Python (or even with ncurses
itself).
--
Comment By: Jan Palus (atler_)
Date: 2006-04-10 23:24
Message:
Logged In: YES
user_id=1497957
loewis: removing lines refering to ncursesw solves the
problem. ncurses.py runs fine as well as other programs.
What is actual problem then? Something with ncursesw or
with python?
Anyway, Thanks for your help.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 22:58
Message:
Logged In: YES
user_id=21627
atler_: around line 427, you find
if self.compiler.find_library_file(lib_dirs,
'ncursesw'):
readline_libs.append('ncursesw')
elif self.compiler.find_library_file(lib_dirs,
'ncurses'):
Replace that with
if self.compiler.find_library_file(lib_dirs,
'ncurses'):
(i.e. dropping the ncursesw part), and rebuild.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 15:48
Message:
Logged In: YES
user_id=1497957
More complete backtrace, I hope it will help:
http://pastebin.com/649445
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 14:14
Message:
Logged In: YES
user_id=29957
The buildbot boxes don't show this problem.
You might need to rebuild a Python with -g and unstripped to
get a useful backtrace.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 12:51
Message:
Logged In: YES
user_id=1497957
$ ldd /usr/lib/python2.4/lib-dynload/_curses.so
libncursesw.so.5 => /usr/lib/libncursesw.so.5
(0x7004c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7008)
libc.so.6 => /lib/libc.so.6 (0x700e4000)
libdl.so.2 => /lib/libdl.so.2 (0x70228000)
libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000)
/lib/ld-linux.so.2 (0x7000)
...
Program received signal SIGSEGV, Segmentation fault.
0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
gdb) bt
#0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
#1 0x706254b8 in ?? () from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
#2 0x706254b8 in ?? () from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
Previous frame identical to this frame (corrupt stack?)
It seems that only programs using panel library cause
segfaults (all other demos run fine except ncurses.py),
sorry for a mistake in a last post.
loewis: I'm not sure I understand second point. What excatly
should be changed in setup.py?
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-09 12:46
Message:
Logged In: YES
user_id=1126061
Cannot reproduce on Gentoo. All the files in the Demo/curses
directory run fine.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 12:29
Message:
Logged In: YES
user_id=21627
I can't reproduce any of this on Debian;
Demo/curses/ncurses.py runs fine. Can you please
1. run ldd on _curses.so, and report the output, and
2. edit setup.py, removing the lines that deal with ncursesw,
3. atler_: produce a gdb backtrace on the time of the crash,
4: vnainar: please report what you mean by "does not work".
Does it erase your hard disk? turn off the machine? Paint
things blue instead of red?
--
Comment By: Jan Palus (atler_)
[ python-Bugs-214033 ] re incompatibility in sre
Bugs item #214033, was opened at 2000-09-11 08:24 Message generated for change (Settings changed) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&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: Extension Modules Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: re incompatibility in sre Initial Comment: [submitted by Adam Sampson] Under Python 1.5.2, I had a script containing the following line: m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url) Under 1.6, this fails with: [...] File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat I can narrow it down to: >>> m = re.match(r"(x?)?", url) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat whereas: >>> m = re.match(r"(x?.)?", url) works fine. Is this correct behaviour for SRE, or am I just being stupid? "(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl too)... -- >Comment By: Trent Mick (tmick) Date: 2006-04-10 23:11 Message: Logged In: YES user_id=34892 I've run into another incarnation of this (it breaks in Python 2.3.5 and Python 2.4.3): >>> import sre >>> sre.compile("(a*)?") Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\Lib\sre.py", line 180, in compile return _compile(pattern, flags) File "C:\Python24\Lib\sre.py", line 227, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat Now granted that the '?' here is redundant for the '*' quantifier on 'a', but compiling this regex works with Python 2.3's "pre" and it works in Perl. The actual use case I've hit here is trying to compile all the regex's in Fedora Core 5's SELinux config files (/etc/selinux/targeted/contexts/files/file_contexts*). The first such regex that broke was: '/usr/share/selinux-policy([^/]*)?/html(/.*)?' -- Comment By: Martin v. Löwis (loewis) Date: 2000-10-01 18:13 Message: Yes, it is still broken in 2.0b2. -- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-01 04:33 Message: Martin, is this still broken in 2.0? Fredrik, any idea? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-214033 ] re incompatibility in sre
Bugs item #214033, was opened at 2000-09-11 08:24 Message generated for change (Settings changed) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&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: Extension Modules Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: re incompatibility in sre Initial Comment: [submitted by Adam Sampson] Under Python 1.5.2, I had a script containing the following line: m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url) Under 1.6, this fails with: [...] File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat I can narrow it down to: >>> m = re.match(r"(x?)?", url) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat whereas: >>> m = re.match(r"(x?.)?", url) works fine. Is this correct behaviour for SRE, or am I just being stupid? "(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl too)... -- Comment By: Trent Mick (tmick) Date: 2006-04-10 23:11 Message: Logged In: YES user_id=34892 I've run into another incarnation of this (it breaks in Python 2.3.5 and Python 2.4.3): >>> import sre >>> sre.compile("(a*)?") Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\Lib\sre.py", line 180, in compile return _compile(pattern, flags) File "C:\Python24\Lib\sre.py", line 227, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat Now granted that the '?' here is redundant for the '*' quantifier on 'a', but compiling this regex works with Python 2.3's "pre" and it works in Perl. The actual use case I've hit here is trying to compile all the regex's in Fedora Core 5's SELinux config files (/etc/selinux/targeted/contexts/files/file_contexts*). The first such regex that broke was: '/usr/share/selinux-policy([^/]*)?/html(/.*)?' -- Comment By: Martin v. Löwis (loewis) Date: 2000-10-01 18:13 Message: Yes, it is still broken in 2.0b2. -- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-01 04:33 Message: Martin, is this still broken in 2.0? Fredrik, any idea? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465838 ] HP-UX11i: illegal combination of compilation and link flags
Bugs item #1465838, was opened at 2006-04-06 09:53 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11i: illegal combination of compilation and link flags Initial Comment: According to Boris Gubenko from the HP-UX compiler development team, it is illegal to link with -lpthread if the sources are not compiled with -mt. However, this is exactly what happens during Python installation, e.g.: cc -Ae -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Python/compile.o Python/compile.c ... aCC -Wl,-E -Wl,+s -o python \ Modules/python.o \ libpython2.5.a -lnsl -lrt -ldld -ldl -lpthread -lm This illegal combination of compilation and link flags eventually results in obscure runtime failures (segfault, abort) while running Boost.Python C++ extensions. These failures go away if Python is installed with, e.g.: env CXX="aCC -mt" BASECFLAGS="-mt" ./configure --without-gcc I suggest changing the configure/make files to always include "-mt" if threading is enabled. BTW: The same issue already exists for Python 2.4. Cheers, Ralf -- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-04-10 16:58 Message: Logged In: YES user_id=71407 Boris Gubenko from HP provides this information: Hi Ralf, the -mt option sets -lpthread link option and defines various macros related to multithreading, including _REENTRANT macro. It must be specified when compiling/linking a multithreaded application. The -mt option is supported in latest aCC compilers, including the aCC V6 compiler (available on IA64 only). I'm not sure if -mt is supported in old aCC V3 compiler available on PA-RISC only, but since Python cannot be compiled with this compiler, this question is, probably, moot. If configuration script wants to be selective about the aCC compiler version, it can check __HP_aCC macro predefined by the compiler and apply '-mt' if __HP_aCC >= 6. As for the gnu compiler, I think, that the equivalent of '-mt' would be '-pthreads' (for cxx on Tru64, it would be '-pthread'). I don't know how to reply to the post on Python forum you've referred me to. I guess, I'd need to register for an account. I can do it if you want me to. Or you can just post it on my behalf. Thanks, Boris - Original Message - From: "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, April 09, 2006 2:11 PM Subject: HP-UX Python configure Hi Boris, Could you please help out here? https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 Especially with this question: "Is this option for all versions?" Thank you in advance! Cheers, Ralf -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-04-10 12:44 Message: Logged In: YES user_id=71407 > Hm. We need to detect if we're on HP/UX, of course. Is > this option for all versions? I guess so since it seems very fundamental, but I am not sure. I alerted Boris Gubenko to this problem report. I hope he will help out. > And I assume it's only for the HP compiler, not gcc? I don't know. I imagine gcc has similar issues since it does link with the same -lpthread eventually. Note that the machine I used is publically accessible: http://www.testdrive.hp.com/ After you register on the web: telnet td176.testdrive.hp.com gcc 3.4.3 is installed. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 08:30 Message: Logged In: YES user_id=29957 Hm. We need to detect if we're on HP/UX, of course. Is this option for all versions? And I assume it's only for the HP compiler, not gcc? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465838&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467080 ] Many functions in socket module are not thread safe
Bugs item #1467080, was opened at 2006-04-09 01:09 Message generated for change (Comment added) made by sobomax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&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: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. -- >Comment By: Maxim Sobolev (sobomax) Date: 2006-04-11 00:08 Message: Logged In: YES user_id=24670 Sorry, for some reason the patch did not go through first time. See attached. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-09 21:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 14:17
Message generated for change (Comment added) made by vnainar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&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: nomind (vnainar)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses library in python 2.4.3 broken
Initial Comment:
My python programs using curses library do not work
with version 2.4.3.Even the 'ncurses.py ' demo program
in the Demo/curses directory does not work correctly.
The problem seems to be in the 'panels' library
--
>Comment By: nomind (vnainar)
Date: 2006-04-11 10:43
Message:
Logged In: YES
user_id=1493752
Removing 'ncursesw' (there are two references to it in
'setup.py') seems to solve the problem. I noticed one more
oddity. Even before the above recompilation , it ran fine
on an Xterm !
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 03:58
Message:
Logged In: YES
user_id=21627
That's hard to tell. Somebody would have to debug ncurses to
find out why it crashes. Notice that it crashes only on some
installations, so it is likely rather a problem with your
ncurses installation, than with Python (or even with ncurses
itself).
--
Comment By: Jan Palus (atler_)
Date: 2006-04-11 02:54
Message:
Logged In: YES
user_id=1497957
loewis: removing lines refering to ncursesw solves the
problem. ncurses.py runs fine as well as other programs.
What is actual problem then? Something with ncursesw or
with python?
Anyway, Thanks for your help.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-10 02:28
Message:
Logged In: YES
user_id=21627
atler_: around line 427, you find
if self.compiler.find_library_file(lib_dirs,
'ncursesw'):
readline_libs.append('ncursesw')
elif self.compiler.find_library_file(lib_dirs,
'ncurses'):
Replace that with
if self.compiler.find_library_file(lib_dirs,
'ncurses'):
(i.e. dropping the ncursesw part), and rebuild.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 19:18
Message:
Logged In: YES
user_id=1497957
More complete backtrace, I hope it will help:
http://pastebin.com/649445
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 17:44
Message:
Logged In: YES
user_id=29957
The buildbot boxes don't show this problem.
You might need to rebuild a Python with -g and unstripped to
get a useful backtrace.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 16:21
Message:
Logged In: YES
user_id=1497957
$ ldd /usr/lib/python2.4/lib-dynload/_curses.so
libncursesw.so.5 => /usr/lib/libncursesw.so.5
(0x7004c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7008)
libc.so.6 => /lib/libc.so.6 (0x700e4000)
libdl.so.2 => /lib/libdl.so.2 (0x70228000)
libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000)
/lib/ld-linux.so.2 (0x7000)
...
Program received signal SIGSEGV, Segmentation fault.
0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
gdb) bt
#0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
#1 0x706254b8 in ?? () from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
#2 0x706254b8 in ?? () from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
Previous frame identical to this frame (corrupt stack?)
It seems that only programs using panel library cause
segfaults (all other demos run fine except ncurses.py),
sorry for a mistake in a last post.
loewis: I'm not sure I understand second point. What excatly
should be changed in setup.py?
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-09 16:16
Message:
Logged In: YES
user_id=1126061
Cannot reproduce on Gentoo. All the files in the Demo/curses
directory run fine.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 15:59
Message:
Logged In: YES
user_id=21627
I can't reproduce any of this on Debian;
Demo/curses/ncurses.py runs fine. Can you please
1. run ldd on _curses.so, and report the output, and
2. edit setup.p
[ python-Bugs-1467080 ] Many functions in socket module are not thread safe
Bugs item #1467080, was opened at 2006-04-09 03:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&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: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-11 07:22 Message: Logged In: YES user_id=21627 Why is it necessary to allocate the memory dynamically? Couldn't the caller provide the memory on the stack (i.e. through a local variable)? -- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-11 02:08 Message: Logged In: YES user_id=24670 Sorry, for some reason the patch did not go through first time. See attached. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-09 23:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 10:47
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&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: nomind (vnainar)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses library in python 2.4.3 broken
Initial Comment:
My python programs using curses library do not work
with version 2.4.3.Even the 'ncurses.py ' demo program
in the Demo/curses directory does not work correctly.
The problem seems to be in the 'panels' library
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 07:32
Message:
Logged In: YES
user_id=21627
Ah, ok. vnainar, atler_: What terminal had you been using to
make it crash? What is your locale? Any other conditions
that might be relevant (e.g. dimension of the terminal)?
--
Comment By: nomind (vnainar)
Date: 2006-04-11 07:13
Message:
Logged In: YES
user_id=1493752
Removing 'ncursesw' (there are two references to it in
'setup.py') seems to solve the problem. I noticed one more
oddity. Even before the above recompilation , it ran fine
on an Xterm !
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 00:28
Message:
Logged In: YES
user_id=21627
That's hard to tell. Somebody would have to debug ncurses to
find out why it crashes. Notice that it crashes only on some
installations, so it is likely rather a problem with your
ncurses installation, than with Python (or even with ncurses
itself).
--
Comment By: Jan Palus (atler_)
Date: 2006-04-10 23:24
Message:
Logged In: YES
user_id=1497957
loewis: removing lines refering to ncursesw solves the
problem. ncurses.py runs fine as well as other programs.
What is actual problem then? Something with ncursesw or
with python?
Anyway, Thanks for your help.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 22:58
Message:
Logged In: YES
user_id=21627
atler_: around line 427, you find
if self.compiler.find_library_file(lib_dirs,
'ncursesw'):
readline_libs.append('ncursesw')
elif self.compiler.find_library_file(lib_dirs,
'ncurses'):
Replace that with
if self.compiler.find_library_file(lib_dirs,
'ncurses'):
(i.e. dropping the ncursesw part), and rebuild.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 15:48
Message:
Logged In: YES
user_id=1497957
More complete backtrace, I hope it will help:
http://pastebin.com/649445
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 14:14
Message:
Logged In: YES
user_id=29957
The buildbot boxes don't show this problem.
You might need to rebuild a Python with -g and unstripped to
get a useful backtrace.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 12:51
Message:
Logged In: YES
user_id=1497957
$ ldd /usr/lib/python2.4/lib-dynload/_curses.so
libncursesw.so.5 => /usr/lib/libncursesw.so.5
(0x7004c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7008)
libc.so.6 => /lib/libc.so.6 (0x700e4000)
libdl.so.2 => /lib/libdl.so.2 (0x70228000)
libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000)
/lib/ld-linux.so.2 (0x7000)
...
Program received signal SIGSEGV, Segmentation fault.
0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
gdb) bt
#0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
#1 0x706254b8 in ?? () from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
#2 0x706254b8 in ?? () from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
Previous frame identical to this frame (corrupt stack?)
It seems that only programs using panel library cause
segfaults (all other demos run fine except ncurses.py),
sorry for a mistake in a last post.
loewis: I'm not sure I understand second point. What excatly
should be changed in setup.py?
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-09 12:46
Message:
Logged In: YES
user_id=1126061
Cannot reproduce on Gentoo. All the files in the Demo/curses
dire
[ python-Bugs-1468223 ] Hitting CTRL-C while in a loop closes IDLE on cygwin
Bugs item #1468223, was opened at 2006-04-11 09:01 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=1468223&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Hitting CTRL-C while in a loop closes IDLE on cygwin Initial Comment: Try the following: >>> while 1: print 1 1 1 1 ... Not hit CTRL-C IDLE will close When hitting CTRL-C when IDLE is idle (huh), the regular KeyboardInterrupt is shown This happens on Cygwin (but not on Linux) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1468231 ] test_grp test_pwd fail on Linux
Bugs item #1468231, was opened at 2006-04-11 09:29 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=1468231&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: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp test_pwd fail on Linux Initial Comment: Python 2.5a1, SUSE Linux test_grp test_pwd fails when running "make test" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468231&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467952 ] os.listdir on Linux returns empty list on some errors
Bugs item #1467952, was opened at 2006-04-10 20:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467952&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: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gary Stiehr (gstiehr) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir on Linux returns empty list on some errors Initial Comment: os.listdir() (defined in the posix_listdir() function on line 1449 of Modules/posixmodule.c in the Python-2.4.3 source distribution) does not check for an error condition when it calls the readdir() system call on line 1665 of posixmodule.c. According to the readdir(3) man page included the Scientific Linux 4.2 (based off of Red Hat Enterprise Linux 4 sources): The readdir() function returns a pointer to a dirent structure, or NULL if an error occurs or end-of-file is reached. It seems that the posix_listdir() function assumes that NULL can only mean end-of-file. Therefore, in the situation where readdir() returns NULL due to some error, such as an I/O Error, posix_listdir() ends the while loop started at line 1665 and goes to the closedir() call at line 1702. This results in an os.listdir() call returning an empty list (as if the directory had no contents) instead of raising an exception. This error was noticed because we performed an ls in a particular directory and it returned with an I/O error. I was then writing a python script to monitor for this condition when I found that the os.listdir() in this directory returned an empty list instead of an I/O error. This behavior was noticed using Python 2.3.4; I looked at the latest (as of 2006-04-07) stable release source (Python 2.4.3) to investigate and to provide the details in this bug report. I also took a quick look at the most recent 2.5.x code and although the posix_listdir function has changed, it still appears as if it would return an empty list if the readdir() call returns NULL. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-11 06:51 Message: Logged In: YES user_id=849994 Thank you for the report, fixed in rev. 45259, 45260. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467952&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
