[ python-Bugs-1110478 ] os.environ.update doesn't work
Bugs item #1110478, was opened at 2005-01-27 08:22
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110478&group_id=5470
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: June Kim (juneaftn)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.environ.update doesn't work
Initial Comment:
os.environ.update doesn't really update os.environ --
it doesn't call putenv subsequently.
This is the test code:
#test1.py
import os
FILENAME='test2.py'
env={};env['ENVIRON_UPDATE']='123';os.environ.update(env)
os.environ['ENVIRON_DIRECT_SETTING']='123'
cmdline='c:\python24\python.exe -u %s'%FILENAME
fs=os.popen3(cmdline,'b')
print fs[1].read()
#test2.py
import os
if os.environ.has_key('ENVIRON_UPDATE'):print
'os.env.update worked'
else:print 'os.env.update failed'
if os.environ.has_key('ENVIRON_DIRECT_SETTING'):print
'os.env assignment worked'
else:print 'os.env assignment failed'
Run test1.py with python 2.4 on windows.
The reason os.environ.update doesn't work is the update
method is removed from 2.4. (It works with 2.3)
Following is the patch:
--- os.py Thu Jan 27 07:09:38 2005
+++ os_new.py Thu Jan 27 07:10:44 2005
@@ -435,6 +435,9 @@
return key.upper() in self.data
def get(self, key, failobj=None):
return self.data.get(key.upper(), failobj)
+def update(self, dict):
+for k, v in dict.items():
+self[k] = v
def copy(self):
return dict(self)
@@ -446,6 +449,9 @@
def __setitem__(self, key, item):
putenv(key, item)
self.data[key] = item
+def update(self, dict):
+for k, v in dict.items():
+self[k] = v
try:
unsetenv
except NameError:
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-01-29 14:34
Message:
Logged In: YES
user_id=21627
Thanks for the report. Fixed in
os.py 1.85
test_os.py 1.29
NEWS 1.1235
os.py 1.83.2.1
NEWS 1.1193.2.17
--
Comment By: June Kim (juneaftn)
Date: 2005-01-27 08:39
Message:
Logged In: YES
user_id=116941
The update methods in os.py were removed in the Revision
1.75. Thu Mar 4 08:25:44 2004 UTC according to the cvs.
--
Comment By: June Kim (juneaftn)
Date: 2005-01-27 08:22
Message:
Logged In: YES
user_id=116941
This is the cause of the cgi bug #1100235.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110478&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1100235 ] Scripts started with CGIHTTPServer: missing cgi environment
Bugs item #1100235, was opened at 2005-01-11 17:00
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100235&group_id=5470
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: pacote (pacote)
Assigned to: Nobody/Anonymous (nobody)
Summary: Scripts started with CGIHTTPServer: missing cgi environment
Initial Comment:
With Python 2.4 only (2.3 works fine). Tested on
Windows 2000.
In run_cgi, sys.environ is updated with cgi variables
(QUERY_STRING, etc.)
but it seems that this environment is not passed to the
child process.
On Windows os.popen3 is used but something must have
changed in that function that is causing this regression.
The attached patch fixes this using the subprocess module.
It fixes also (I think) bug 1088039
("directories/scripts with spaces in their name").
Supports too Python installed in a directory with a
space (e.g. "Program Files").
Patch note: the subprocess test (have_subprocess) is
kind of awkward: is there a better way to do this?
Diff follows, complete script attached.
-
--- C:\apps\Python24\Lib\CGIHTTPServer-old.py Mon Aug
30 09:38:16 2004
+++ C:\apps\Python24\Lib\CGIHTTPServer.py Tue Jan 10
19:45:09 2005
@@ -234,18 +234,16 @@
elif self.have_popen2 or self.have_popen3:
# Windows -- use popen2 or popen3 to
create a subprocess
+import subprocess
import shutil
-if self.have_popen3:
-popenx = os.popen3
-else:
-popenx = os.popen2
-cmdline = scriptfile
+
+cmdline = '"%s"' % scriptfile
if self.is_python(scriptfile):
interp = sys.executable
if interp.lower().endswith("w.exe"):
# On Windows, use python.exe, not
pythonw.exe
interp = interp[:-5] + interp[-4:]
-cmdline = "%s -u %s" % (interp, cmdline)
+cmdline = '"%s" -u %s' % (interp, cmdline)
if '=' not in query and '"' not in query:
cmdline = '%s "%s"' % (cmdline, query)
self.log_message("command: %s", cmdline)
@@ -253,11 +251,11 @@
nbytes = int(length)
except (TypeError, ValueError):
nbytes = 0
-files = popenx(cmdline, 'b')
-fi = files[0]
-fo = files[1]
-if self.have_popen3:
-fe = files[2]
+
+p = subprocess.Popen(cmdline,
stdin=subprocess.PIPE, stdout=subprocess.PIPE,
+
stderr=subprocess.PIPE, env=os.environ)
+(fi, fo, fe) = (p.stdin, p.stdout, p.stderr)
+
if self.command.lower() == "post" and
nbytes > 0:
data = self.rfile.read(nbytes)
fi.write(data)
@@ -267,16 +265,16 @@
break
fi.close()
shutil.copyfileobj(fo, self.wfile)
-if self.have_popen3:
-errors = fe.read()
-fe.close()
-if errors:
-self.log_error('%s', errors)
+errors = fe.read()
+fe.close()
+if errors:
+self.log_error('%s', errors)
sts = fo.close()
if sts:
self.log_error("CGI script exit status
%#x", sts)
else:
self.log_message("CGI script exited OK")
+del p
else:
# Other O.S. -- execute script in this process
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-01-29 14:34
Message:
Logged In: YES
user_id=21627
As juneaftn says, this was caused by #1110478, and is fixed in
os.py 1.85
test_os.py 1.29
NEWS 1.1235
os.py 1.83.2.1
NEWS 1.1193.2.17
--
Comment By: June Kim (juneaftn)
Date: 2005-01-27 08:24
Message:
Logged In: YES
user_id=116941
Please have a look at #1110478. The cause is in os.py.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100235&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1110007 ] Cannot ./configure on FC3 with gcc 3.4.2
Bugs item #1110007, was opened at 2005-01-26 17:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 Category: Build >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Paul Watson (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot ./configure on FC3 with gcc 3.4.2 Initial Comment: Trying to run ./configure fails with the message: configure: error: cannot run C++ compiled programs. The config.log file reports: version 'GCC_3.3' not found (required by usr/lib/libstdc++.so.6) FC3 is delivered with gcc 3.4.2. What is the best path to a fix for this? Must I regress to an older compiler? -- >Comment By: Martin v. Löwis (loewis) Date: 2005-01-29 15:08 Message: Logged In: YES user_id=21627 This is clearly a bug in your gcc installation - perhaps some library is not up-to-date, or libstdc++ was compiled with the wrong compiler. You should report this to the FC3 developers. As a work-around, you can configure your Python --without-cxx. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1106057 ] README of 2.4 source download says 2.4a3
Bugs item #1106057, was opened at 2005-01-20 16:42 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106057&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Roger Erens (rogererens) Assigned to: Nobody/Anonymous (nobody) Summary: README of 2.4 source download says 2.4a3 Initial Comment: When using the links http://www.python.org/ftp/python/2.4/Python-2.4.tgz or http://www.python.org/ftp/python/2.4/Python-2.4.tar.bz2 I get to see Python2.4-a3 in the README. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-01-29 15:17 Message: Logged In: YES user_id=21627 For 2.4.0, this cannot be fixed anymore. For 2.4.1, the version number in the README was changed to 2.4 in 1.184.2.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106057&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1070140 ] endianness detection fails on IRIX 5.3
Bugs item #1070140, was opened at 2004-11-20 20:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070140&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Georg Schwarz (gschwarz) Assigned to: Nobody/Anonymous (nobody) Summary: endianness detection fails on IRIX 5.3 Initial Comment: Configuring python 2.3.4 on IRIX 5.3 fails as follows: checking whether byte ordering is bigendian... unknown configure: error: unknown endianness presetting ac_cv_c_bigendian=no (or yes) will help *** Error code 1 The problem is that the respective defines are in sys/ endian.h, which is not being included in the test code. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-01-29 15:22 Message: Logged In: YES user_id=21627 Unfortunately, there is not much we can do about this (with acceptable efforts); we use the AC_C_BIGENDIAN macro of autoconf which probably needs to be changed. It would be best if you could report this problem to autoconf. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070140&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1110705 ] list comprehension scope
Bugs item #1110705, was opened at 2005-01-27 05:27 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Simon Dahlbacka (sdahlbac) Assigned to: Nobody/Anonymous (nobody) Summary: list comprehension scope Initial Comment: The variable used for iteration in list comprehensions is still in scope after the list comprehension. >>>foo = [1, 2, 3] >>>bar = [dummy + 1 for dummy in foo] >>>dummy 3 Expected result: NameError: name 'dummy' is not defined -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 11:54 Message: Logged In: YES user_id=341410 "this behavior is deprecated, and relying on it will not work once this bug is fixed in a future release" As we have not yet reached the future release in which this will happen, and the 'bug' is both known and documented, it will be 'fixed' when it is fixed. The reason that it has not yet been 'fixed' is because there is a nontrivial amount of code that would break if it was. I personally would call it a deprecated 'feature'. Then again, I use it more often than I should. -- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-01-27 06:11 Message: Logged In: YES user_id=750513 Seemingly (according to: http://docs.python.org/ref/lists.html) this is indeed a bug that should be fixed. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-27 05:48 Message: Logged In: YES user_id=80475 This is not a bug. It is behaving as designed. The thought was to emulate the behavior of an equivalent for-loop. In future versions of Python, Guido would like to change the design to hide the induction variable. So, someday, you'll get your wish. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1108490 ] broken link in tkinter docs
Bugs item #1108490, was opened at 2005-01-24 18:35 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108490&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: broken link in tkinter docs Initial Comment: "Compound" link on http://www.python.org/doc/current/lib/node721.html is broken. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-29 20:54 Message: Logged In: YES user_id=469548 Fixed in maint24 and HEAD. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108490&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1110055 ] recursion core dumps
Bugs item #1110055, was opened at 2005-01-26 11:18 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jacob Engelbrecht (jengeldk) Assigned to: Nobody/Anonymous (nobody) Summary: recursion core dumps Initial Comment: when running recursive function you get a coredump with deep recursion. eg from sys import * n = 3 setrecursionlimit(n+1) def fact(n): if n==1: return 1 return fact(n-1)*n fact(n) This is seen on linux i686 with both python2.3 and python2.4, the recursion depth which triggers the core dump is 26211 with python2.4 and 29123 with python2.3 with a machine having 2076860 kB of memory, on machines with less memory smaller numbers are seen. this is what gdb tells me: [EMAIL PROTECTED]:/scratch/jacob$ gdb /usr/bin/python2.4 core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) Core was generated by `python2.4 /home/user_4/jacob/rr 3'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/tls/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libdl.so.2 Reading symbols from /lib/tls/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libutil.so.1 Reading symbols from /lib/tls/libm.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400c94bf in mallopt () from /lib/tls/libc.so.6 -- Comment By: logistix (logistix) Date: 2005-01-29 14:12 Message: Logged In: YES user_id=699438 This looks like a stack overflow. There's not much python can do when the stack runs out of memory, which is why the default recursion limit is set to 1000. Also, at least in the reproducable, the number you are building is going to consume excessive amounts of memory. I ran this test (to avoid creating a giant long number) and still got the segfault. from sys import * n = 3 setrecursionlimit(n+1) def nofact(n): if n==1: return 1 return nofact(n-1) nofact(n) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1110055 ] recursion core dumps
Bugs item #1110055, was opened at 2005-01-26 09:18 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jacob Engelbrecht (jengeldk) Assigned to: Nobody/Anonymous (nobody) Summary: recursion core dumps Initial Comment: when running recursive function you get a coredump with deep recursion. eg from sys import * n = 3 setrecursionlimit(n+1) def fact(n): if n==1: return 1 return fact(n-1)*n fact(n) This is seen on linux i686 with both python2.3 and python2.4, the recursion depth which triggers the core dump is 26211 with python2.4 and 29123 with python2.3 with a machine having 2076860 kB of memory, on machines with less memory smaller numbers are seen. this is what gdb tells me: [EMAIL PROTECTED]:/scratch/jacob$ gdb /usr/bin/python2.4 core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) Core was generated by `python2.4 /home/user_4/jacob/rr 3'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/tls/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libdl.so.2 Reading symbols from /lib/tls/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libutil.so.1 Reading symbols from /lib/tls/libm.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400c94bf in mallopt () from /lib/tls/libc.so.6 -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 12:16 Message: Logged In: YES user_id=341410 The fact that an error occurs is not surprising. Python is limited by the C stack size, which from what I understand is well below 2GB. The fact that it gets to nearly 30k levels of recursion for you is amazing to me, the most used platform (Windows) can only ever get to around 5500 levels before they get "MemoryError: stack overflow" exceptions. I believe that the reason you are getting a segfault on linux is the way the linux malloc() and free() work. Specifically, malloc() on linux will give you a pointer to memory, regardless of whether it is available. If your program has used up all of its stack space, and you need more, the pointer will be invalid. If Python happens to call a free() before you actually access the invalid pointer, everything will work. If Python doesn't call free() before you access the invalid pointer, you get a segfault. Unfortunately, there is no way that Python (or any other program on linux) can know that the pointer it has gotten from malloc() is invalid. Furthermore, as per the docs here: http://docs.python.org/lib/module-sys.html " setrecursionlimit(limit) Set the maximum depth of the Python interpreter stack to limit. This limit prevents infinite recursion from causing an overflow of the C stack and crashing Python. The highest possible limit is platform-dependent. A user may need to set the limit higher when she has a program that requires deep recursion and a platform that supports a higher limit. This should be done with care, because a too-high limit can lead to a crash." I would suggest that this bug be closed as "3rd party, will not fix", and suggest the OP read the documentation. -- Comment By: logistix (logistix) Date: 2005-01-29 12:12 Message: Logged In: YES user_id=699438 This looks like a stack overflow. There's not much python can do when the stack runs out of memory, which is why the default recursion limit is set to 1000. Also, at least in the reproducable, the number you are building is going to consume excessive amounts of memory. I ran this test (to avoid creating a giant long number) and still got the segfault. from sys import * n = 3 setrecursionlimit(n+1) def nofact(n): if n==1: return 1 return nofact(n-1) nofact(n) -
[ python-Bugs-1110055 ] recursion core dumps
Bugs item #1110055, was opened at 2005-01-26 12:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110055&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jacob Engelbrecht (jengeldk) Assigned to: Nobody/Anonymous (nobody) Summary: recursion core dumps Initial Comment: when running recursive function you get a coredump with deep recursion. eg from sys import * n = 3 setrecursionlimit(n+1) def fact(n): if n==1: return 1 return fact(n-1)*n fact(n) This is seen on linux i686 with both python2.3 and python2.4, the recursion depth which triggers the core dump is 26211 with python2.4 and 29123 with python2.3 with a machine having 2076860 kB of memory, on machines with less memory smaller numbers are seen. this is what gdb tells me: [EMAIL PROTECTED]:/scratch/jacob$ gdb /usr/bin/python2.4 core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) Core was generated by `python2.4 /home/user_4/jacob/rr 3'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/tls/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libdl.so.2 Reading symbols from /lib/tls/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libutil.so.1 Reading symbols from /lib/tls/libm.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400c94bf in mallopt () from /lib/tls/libc.so.6 -- >Comment By: Tim Peters (tim_one) Date: 2005-01-29 15:20 Message: Logged In: YES user_id=31435 The docs for setrecursionlimit() are indeed already quite clear that you boost its default value at your own risk. So this isn't a bug, it's a documented limitation. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 15:16 Message: Logged In: YES user_id=341410 The fact that an error occurs is not surprising. Python is limited by the C stack size, which from what I understand is well below 2GB. The fact that it gets to nearly 30k levels of recursion for you is amazing to me, the most used platform (Windows) can only ever get to around 5500 levels before they get "MemoryError: stack overflow" exceptions. I believe that the reason you are getting a segfault on linux is the way the linux malloc() and free() work. Specifically, malloc() on linux will give you a pointer to memory, regardless of whether it is available. If your program has used up all of its stack space, and you need more, the pointer will be invalid. If Python happens to call a free() before you actually access the invalid pointer, everything will work. If Python doesn't call free() before you access the invalid pointer, you get a segfault. Unfortunately, there is no way that Python (or any other program on linux) can know that the pointer it has gotten from malloc() is invalid. Furthermore, as per the docs here: http://docs.python.org/lib/module-sys.html " setrecursionlimit(limit) Set the maximum depth of the Python interpreter stack to limit. This limit prevents infinite recursion from causing an overflow of the C stack and crashing Python. The highest possible limit is platform-dependent. A user may need to set the limit higher when she has a program that requires deep recursion and a platform that supports a higher limit. This should be done with care, because a too-high limit can lead to a crash." I would suggest that this bug be closed as "3rd party, will not fix", and suggest the OP read the documentation. -- Comment By: logistix (logistix) Date: 2005-01-29 15:12 Message: Logged In: YES user_id=699438 This looks like a stack overflow. There's not much python can do when the stack runs out of memory, which is why the default recursion limit is set to 1000. Also, a
[ python-Bugs-1108992 ] idle freezes when run over ssh
Bugs item #1108992, was opened at 2005-01-25 02:44 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 12:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 01:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1058960 ] install_lib fails under Python 2.1
Bugs item #1058960, was opened at 2004-11-02 17:57 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058960&group_id=5470 Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: install_lib fails under Python 2.1 Initial Comment: distutils/command/install_lib.py references os.extsep. os.extsep is only available in pythons >= 2.2 (The result, naturally, is an uncaught AttributeError.) Here's a quick patch (though the patch is flawed if os.extsep is ever anything but '.' --- is it?) Begin Patch Index: cvs.2/distutils/command/install_lib.py --- cvs.2/distutils/command/install_lib.py Mon, 25 Oct 2004 13:00:15 -0700 dairiki (distutils/b/43_install_li 1.1 644) +++ cvs.2(w)/distutils/command/install_lib.py Tue, 02 Nov 2004 09:48:17 -0800 dairiki (distutils/b/43_install_li 1.1 644) @@ -9,7 +9,10 @@ # Extension for Python source files. -PYTHON_SOURCE_EXTENSION = os.extsep + "py" +try: +PYTHON_SOURCE_EXTENSION = os.extsep + "py" +except AttributeError: +PYTHON_SOURCE_EXTENSION = '.py' class install_lib (Command): End Patch -- Comment By: Paul Moore (pmoore) Date: 2005-01-29 21:02 Message: Logged In: YES user_id=113328 This has been fixed in CVS HEAD, and can be closed. It is probably a backport candidate to Python 2.4 (I can't check if that has been done). It's likely too late for 2.3... -- Comment By: Davide Alberani (alberanid) Date: 2004-11-09 12:39 Message: Logged In: YES user_id=170840 A somewhat simpler version: PYTHON_SOURCE_EXTENSION = getattr(os, 'extsep', '.') + "py" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058960&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1016563 ] urllib2 bug in proxy auth
Bugs item #1016563, was opened at 2004-08-26 08:14
Message generated for change (Comment added) made by pmoore
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Christoph Mussenbrock (mussenbrock)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 bug in proxy auth
Initial Comment:
in urllib2.py:
line 502 should be:
... user_pass = base64.encodestring('%s:%s' % (unquote
(user), unquote(password))).strip()
the '.strip()' is missing in the current version ("2.1").
this makes an additonal '\n' at the end of user_pass.
So there will be an empty line in the http header, which
is buggy.
(see also line 645, where the .strip() is right in place!).
Best regards,
Christoph
--
Comment By: Paul Moore (pmoore)
Date: 2005-01-29 21:50
Message:
Logged In: YES
user_id=113328
The change was introduced by revision 1.32 of the file, from
patch 527518. There's no mention of removing strip() there,
so I suspect it was an accident.
The strip() is still missing in CVS HEAD. I can see the
problem, in theory (base64.encodestring returns a string
with a terminating newline). However, I cannot reproduce the
problem.
Can the original poster provide a means of verifying the
problem? It may be useful as a test case.
Regardless, the change seems harmless, and can probably be
applied. I attach a patch against CVS HEAD:
--- urllib2.py.orig 2005-01-09 05:51:49.0 +
+++ urllib2.py 2005-01-29 21:31:49.0 +
@@ -582,7 +582,8 @@
if ':' in user_pass:
user, password = user_pass.split(':', 1)
user_pass = base64.encodestring('%s:%s' %
(unquote(user),
-
unquote(password)))
+
unquote(password))
+ ).strip()
req.add_header('Proxy-authorization',
'Basic ' + user_pass)
host = unquote(host)
req.set_proxy(host, type)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-977250 ] Double __init__.py executing
Bugs item #977250, was opened at 2004-06-22 07:55 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977250&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandre (kuskakus) Assigned to: Nobody/Anonymous (nobody) Summary: Double __init__.py executing Initial Comment: There is some strange feature, looking like a bug. I have 'pkg' dir with 2 files: ./pkg/__init__.py print '__init__.py' ./pkg/test.py print 'test.py' import __init__ Python 2.3.4 (#53, May 25 2004, 21:17:02) >>> import pkg.test __init__.py test.py __init__.py With '-v' option: >>> import pkg.test import pkg # directory pkg # pkg\__init__.pyc matches pkg\__init__.py import pkg # precompiled from pkg\__init__.pyc __init__.py # pkg\test.pyc matches pkg\test.py import pkg.test # precompiled from pkg\test.pyc test.py # pkg\__init__.pyc matches pkg\__init__.py import pkg.__init__ # precompiled from pkg\__init__.pyc __init__.py Why __init__.py executed two times? -- Comment By: Paul Moore (pmoore) Date: 2005-01-29 22:02 Message: Logged In: YES user_id=113328 Essentially, because pkg\__init__.py is loaded into sys.modules under *two* names. First, as pkg (as part of the process of importing pkg.test) and then as pkg.__init__ (explicitly in pkg\test.py). As the source is loaded twice, the print is executed twice. While subtle, this is not a bug. To demonstrate: >>> import sys >>> orig = set(sys.modules.keys()) >>> import pkg.test init init test >>> set(sys.modules.keys()) - orig set(['pkg.test', 'pkg', 'pkg.__init__']) You see, both pkg and pkg.__init__ are separately in sys.modules (even though they refer to the same file). In essence, it is incorrect to import __init__ directly - always import the package. If test.py had said "import pkg", you wouldn't have seen this behaviour, but nothing else would have changed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977250&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-977250 ] Double __init__.py executing
Bugs item #977250, was opened at 2004-06-22 08:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977250&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Alexandre (kuskakus) Assigned to: Nobody/Anonymous (nobody) Summary: Double __init__.py executing Initial Comment: There is some strange feature, looking like a bug. I have 'pkg' dir with 2 files: ./pkg/__init__.py print '__init__.py' ./pkg/test.py print 'test.py' import __init__ Python 2.3.4 (#53, May 25 2004, 21:17:02) >>> import pkg.test __init__.py test.py __init__.py With '-v' option: >>> import pkg.test import pkg # directory pkg # pkg\__init__.pyc matches pkg\__init__.py import pkg # precompiled from pkg\__init__.pyc __init__.py # pkg\test.pyc matches pkg\test.py import pkg.test # precompiled from pkg\test.pyc test.py # pkg\__init__.pyc matches pkg\__init__.py import pkg.__init__ # precompiled from pkg\__init__.pyc __init__.py Why __init__.py executed two times? -- >Comment By: Martin v. Löwis (loewis) Date: 2005-01-30 00:41 Message: Logged In: YES user_id=21627 I agree with that analysis; closing this as invalid. -- Comment By: Paul Moore (pmoore) Date: 2005-01-29 23:02 Message: Logged In: YES user_id=113328 Essentially, because pkg\__init__.py is loaded into sys.modules under *two* names. First, as pkg (as part of the process of importing pkg.test) and then as pkg.__init__ (explicitly in pkg\test.py). As the source is loaded twice, the print is executed twice. While subtle, this is not a bug. To demonstrate: >>> import sys >>> orig = set(sys.modules.keys()) >>> import pkg.test init init test >>> set(sys.modules.keys()) - orig set(['pkg.test', 'pkg', 'pkg.__init__']) You see, both pkg and pkg.__init__ are separately in sys.modules (even though they refer to the same file). In essence, it is incorrect to import __init__ directly - always import the package. If test.py had said "import pkg", you wouldn't have seen this behaviour, but nothing else would have changed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977250&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1058960 ] install_lib fails under Python 2.1
Bugs item #1058960, was opened at 2004-11-02 18:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058960&group_id=5470 Category: Distutils Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: install_lib fails under Python 2.1 Initial Comment: distutils/command/install_lib.py references os.extsep. os.extsep is only available in pythons >= 2.2 (The result, naturally, is an uncaught AttributeError.) Here's a quick patch (though the patch is flawed if os.extsep is ever anything but '.' --- is it?) Begin Patch Index: cvs.2/distutils/command/install_lib.py --- cvs.2/distutils/command/install_lib.py Mon, 25 Oct 2004 13:00:15 -0700 dairiki (distutils/b/43_install_li 1.1 644) +++ cvs.2(w)/distutils/command/install_lib.py Tue, 02 Nov 2004 09:48:17 -0800 dairiki (distutils/b/43_install_li 1.1 644) @@ -9,7 +9,10 @@ # Extension for Python source files. -PYTHON_SOURCE_EXTENSION = os.extsep + "py" +try: +PYTHON_SOURCE_EXTENSION = os.extsep + "py" +except AttributeError: +PYTHON_SOURCE_EXTENSION = '.py' class install_lib (Command): End Patch -- >Comment By: Martin v. Löwis (loewis) Date: 2005-01-30 00:49 Message: Logged In: YES user_id=21627 Closing it as fixed. A backport to 2.3 would be pointless, since 2.3 does have extsep. This change only matters assuming there will be a separate distutils release some day, which is doubtful. -- Comment By: Paul Moore (pmoore) Date: 2005-01-29 22:02 Message: Logged In: YES user_id=113328 This has been fixed in CVS HEAD, and can be closed. It is probably a backport candidate to Python 2.4 (I can't check if that has been done). It's likely too late for 2.3... -- Comment By: Davide Alberani (alberanid) Date: 2004-11-09 13:39 Message: Logged In: YES user_id=170840 A somewhat simpler version: PYTHON_SOURCE_EXTENSION = getattr(os, 'extsep', '.') + "py" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058960&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1110007 ] Cannot ./configure on FC3 with gcc 3.4.2
Bugs item #1110007, was opened at 2005-01-26 10:24 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 Category: Build Group: 3rd Party >Status: Open >Resolution: None Priority: 5 Submitted By: Paul Watson (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot ./configure on FC3 with gcc 3.4.2 Initial Comment: Trying to run ./configure fails with the message: configure: error: cannot run C++ compiled programs. The config.log file reports: version 'GCC_3.3' not found (required by usr/lib/libstdc++.so.6) FC3 is delivered with gcc 3.4.2. What is the best path to a fix for this? Must I regress to an older compiler? -- >Comment By: Paul Watson (liturgist) Date: 2005-01-29 20:38 Message: Logged In: YES user_id=197677 The fc3 group begs to differ with the assessment. Perhaps someone can comment on the response to Buzilla 146563. If this bug is closed again, that's fine. I do not think I would try to reopen it. https://bugzilla.redhat.com/beta/show_bug.cgi?id=146563 --- Additional Comments From [EMAIL PROTECTED] 2005-01-29 14:12 EST --- /usr/local/abinitio/lib/libgcc_s.so.1: version `GCC_3.3' not found (required by /usr/lib/libstdc++.so.6) /usr/local/abinitio/lib/libgcc_s.so.1 is not part of Fedora Core, and is older than the system libgcc_s.so.1 in /lib/. The bug is that you are thus overriding a system library with an incompatible (well, in this case likely just older) one. You need to avoid that. In this particular case I guess just rm -f /usr/local/abinitio/lib/libgcc_s* would DTRT (perhaps make a backup copy of that). But it is certainly not a bug in the distro, but a problem caused by badly packaged 3rd party software. -- Comment By: Martin v. Löwis (loewis) Date: 2005-01-29 08:08 Message: Logged In: YES user_id=21627 This is clearly a bug in your gcc installation - perhaps some library is not up-to-date, or libstdc++ was compiled with the wrong compiler. You should report this to the FC3 developers. As a work-around, you can configure your Python --without-cxx. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1110007 ] Cannot ./configure on FC3 with gcc 3.4.2
Bugs item #1110007, was opened at 2005-01-26 10:24 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 Category: Build Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Paul Watson (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot ./configure on FC3 with gcc 3.4.2 Initial Comment: Trying to run ./configure fails with the message: configure: error: cannot run C++ compiled programs. The config.log file reports: version 'GCC_3.3' not found (required by usr/lib/libstdc++.so.6) FC3 is delivered with gcc 3.4.2. What is the best path to a fix for this? Must I regress to an older compiler? -- >Comment By: Paul Watson (liturgist) Date: 2005-01-29 20:51 Message: Logged In: YES user_id=197677 My apologies. The problem was another libgcc_s.so that was installed by another third-party product, not Python. Once this was removed from LD_LIBRARY_PATH, it appears to be successful. Sorry. -- Comment By: Paul Watson (liturgist) Date: 2005-01-29 20:38 Message: Logged In: YES user_id=197677 The fc3 group begs to differ with the assessment. Perhaps someone can comment on the response to Buzilla 146563. If this bug is closed again, that's fine. I do not think I would try to reopen it. https://bugzilla.redhat.com/beta/show_bug.cgi?id=146563 --- Additional Comments From [EMAIL PROTECTED] 2005-01-29 14:12 EST --- /usr/local/abinitio/lib/libgcc_s.so.1: version `GCC_3.3' not found (required by /usr/lib/libstdc++.so.6) /usr/local/abinitio/lib/libgcc_s.so.1 is not part of Fedora Core, and is older than the system libgcc_s.so.1 in /lib/. The bug is that you are thus overriding a system library with an incompatible (well, in this case likely just older) one. You need to avoid that. In this particular case I guess just rm -f /usr/local/abinitio/lib/libgcc_s* would DTRT (perhaps make a backup copy of that). But it is certainly not a bug in the distro, but a problem caused by badly packaged 3rd party software. -- Comment By: Martin v. Löwis (loewis) Date: 2005-01-29 08:08 Message: Logged In: YES user_id=21627 This is clearly a bug in your gcc installation - perhaps some library is not up-to-date, or libstdc++ was compiled with the wrong compiler. You should report this to the FC3 developers. As a work-around, you can configure your Python --without-cxx. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110007&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1092225 ] IDLE hangs due to subprocess
Bugs item #1092225, was opened at 2004-12-28 10:31
Message generated for change (Comment added) made by kbk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092225&group_id=5470
Category: IDLE
Group: Python 2.3
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: ZACK (kitanek)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE hangs due to subprocess
Initial Comment:
IDLE GUI hangs after some time when launched in the
default mode (i.e. with the subprocess).
I have noticed that the subprocess generates fast
continuous stream of system calls even if the GUI is
not used and not visible (moved to another desktop).
Example output from strace (strace -f idle):
...
[pid 5359] <... select resumed> ) = 0 (Timeout)
[pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0
[pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0
[pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0
[pid 5359] select(4, [3], [], [], {0, 5}
[pid 5355] <... futex resumed> ) = -1 ETIMEDOUT
(Connection timed out)
[pid 5355] write(7, "\0", 1
[pid 5356] <... select resumed> ) = 1 (in [6])
[pid 5355] <... write resumed> ) = 1
[pid 5356] futex(0x81c7250, FUTEX_WAIT, 2, NULL
[pid 5355] futex(0x81c7250, FUTEX_WAKE, 1
[pid 5356] <... futex resumed> ) = -1 EAGAIN
(Resource temporarily unavailable)
[pid 5355] <... futex resumed> ) = 0
[pid 5356] futex(0x81c7250, FUTEX_WAKE, 1
[pid 5355] gettimeofday(
[pid 5356] <... futex resumed> ) = 0
[pid 5355] <... gettimeofday resumed> {1104246902,
467914}, {4294967236, 0}) = 0
[pid 5356] read(6,
[pid 5355] gettimeofday(
[pid 5356] <... read resumed> "\0", 1) = 1
[pid 5355] <... gettimeofday resumed> {1104246902,
468040}, {4294967236, 0}) = 0
[pid 5356] select(7, [6], [], [], NULL
[pid 5355] select(6, [5], [], [], {0, 5}
[pid 5357] <... select resumed> ) = 0 (Timeout)
[pid 5357] futex(0x81fb798, FUTEX_WAKE, 1) = 0
[pid 5357] futex(0x81fb798, FUTEX_WAKE, 1) = 0
[pid 5357] select(0, NULL, NULL, NULL, {0, 5}
[pid 5359] <... select resumed> ) = 0 (Timeout)
[pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0
[pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0
[pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0
...
If IDLE is launched without the subprocess (idle -n)
than it seems to run just fine without the syscall storm:
futex(0x83d1fa0, FUTEX_WAIT, 200, NULL
--
>Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-29 23:25
Message:
Logged In: YES
user_id=149084
No response from OP. Closing as 'worksforme'
--
Comment By: Kurt B. Kaiser (kbk)
Date: 2005-01-01 12:17
Message:
Logged In: YES
user_id=149084
The socket is polled by the GUI and the subprocess. What you
are seeing is the normal delays and polls. Without the
subprocess there is no socket and therefore no polling.
Further information is needed. When IDLE "hangs", does the
GUI become inactive? Can the subprocess be restarted? Is
there any evidence (via ps etc.) that the system is running out
of some resource? Does the problem occur if you send a
continuous stream of characters to stdout? Is the interval
to a "hang" always the same?
--
Comment By: ZACK (kitanek)
Date: 2004-12-28 10:38
Message:
Logged In: YES
user_id=1159448
Sorry, I forgot the system specs:
Debian Linux, unstable branche (SID)
Kernel 2.6.9-1-686
Python 2.3.4 (#2, Dec 3 2004, 13:53:17)
[GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2
glib-config --version = 1.2.10
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092225&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
