[ python-Bugs-1565967 ] pyexpat produces fals parsing results in CharacterDataHandle
Bugs item #1565967, was opened at 2006-09-26 22:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565967&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: XML Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Michael Gebetsroither (einsteinmg) Assigned to: Nobody/Anonymous (nobody) Summary: pyexpat produces fals parsing results in CharacterDataHandle Initial Comment: hi, with bigger files pyexpat begins to split up some things parsed through CharacterDataHandler. c: "root-menu" pyexpat: "root-me" "nu" c: "TopLeft" pyexpat: "TopL" "eft" that strange results are also reproduseable on python2.4 greets -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-27 09:49 Message: Logged In: YES user_id=21627 This is not a bug. Instead, applications are expected to be aware of it, and deal with it accordingly. In general, it is not possible to provide all character data in a single callback, since that may exhaust the available address space. The actual splitting of character data depends on the internal buffering that Expat performs. If the buffer is exhausted in the middle of character data, those data are sent to the application before reading more input. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565967&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory
Bugs item #1565525, was opened at 2006-09-26 08:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-27 09:49 Message: Logged In: YES user_id=21627 I'm still having problems figuring out what the bug is that you are reporting. Ok, in this case, it consumes a lot of memory. Why is that a bug? -- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 05:20 Message: Logged In: YES user_id=731668 I have read the exc_info suggestions before, but they have never made any difference. Neither change you suggest modifies the memory footprint behaviour in any way. Weakrefs might be slow, I offered them as an alternative to just removing the references entirely. I understand this might cause problems with existing code, but the current situation causes a problem which is more difficult to work around. Code that needs locals and globals can explicity store a reference to eat - it is impossible to dig in to the traceback object and remove those references. The use-case of storing the exc_info is fairly simple, for example: Two threads. One queues a task for the other to complete. That task fails an raises an exception. The exc_info is caught, passed back to the first thread, the exc_info is raised from there. The goal is to get the whole execution stack, which it does quite nicely, except that it has this terrible memory side effect. -- Comment By: Tim Peters (tim_one) Date: 2006-09-26 12:04 Message: Logged In: YES user_id=31435 Your memory bloat is mostly due to the d = range(10) line. Python has no problem collecting the cyclic trash, but you're creating 10 * 100 = 10 million integer objects hanging off trash cycles before invoking gc.collect(), and those integers require at least 10 million * 12 ~= 120MB all by themselves. Worse, memory allocated to "short" integers is both immortal and unbounded: it can be reused for /other/ integer objects, but it never goes away. Note that memory usage in your program remains low and steady if you force gc.collect() after every call to bar(). Then you only create 100K integers, instead of 10M, before the trash gets cleaned up. There is no simple-minded way to "repair" this, BTW. For example, /of course/ a frame has to reference all its locals, and moving to weak references for those instead would be insanely inefficient (among other, and deeper, problems). Note that the library reference manual warns against storing the result of exc_info() in a local variable (which you're /effectively/ doing, since the formal parameter `s` is a local variable within foo()), and suggests other approaches. Sorry, but I really couldn't tell from your description why you want to store this stuff in an instance attribute, so can't guess whether another more-or-less obvious approach would help. For example, no cyclic trash is created if you add th
[ python-Bugs-1566140 ] T_ULONG -> double rounding in PyMember_GetOne()
Bugs item #1566140, was opened at 2006-09-27 07:23 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566140&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Piet Delport (pjdelport) Assigned to: Nobody/Anonymous (nobody) Summary: T_ULONG -> double rounding in PyMember_GetOne() Initial Comment: Problem: Python/structmember.c's PyMember_GetOne currently handles getting T_ULONG members as follows: case T_ULONG: v = PyLong_FromDouble((double) *(unsigned long*)addr); break; On platforms with 64-bit longs, the double won't have enough precision to hold big values without rounding. The fix should be simple: v = PyLong_FromUnsignedLong(*(unsigned long*)addr); -- Piet Delport <[EMAIL PROTECTED]> -- Comment By: �iga Seilnacht (zseil) Date: 2006-09-27 10:56 Message: Logged In: YES user_id=1326842 Patch #1549049: http://www.python.org/sf/1549049 has a fix for this and some other bugs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566140&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5
Bugs item #1564763, was opened at 2006-09-24 23:43
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode comparison change in 2.4 vs. 2.5
Initial Comment:
Python 2.5 changed the behavior of unicode comparisons
in a significant way from Python 2.4, causing a test
case failure in a module of mine. All tests passed with
an earlier version of 2.5, though unfortunately I don't
know what version in particular it started failing with.
The following code prints out all True on Python 2.4;
the strings are compared case-insensitively, whether
they are my lowerstr class, real strs, or unicodes. On
Python 2.5, the comparison between lowerstr and unicode
is false, but only in one direction.
If I make lowerstr inherit from unicode rather than
str, all comparisons are true again. So at the very
least, this is internally inconsistent. I also think
changing the behavior between 2.4 and 2.5 constitutes a
serious bug.
--
>Comment By: Armin Rigo (arigo)
Date: 2006-09-27 08:58
Message:
Logged In: YES
user_id=4771
Well, yes, that's what I tried to explain. I also tried to
explain how the 2.5 behavior is the "right" one, and the
previous 2.4 behavior is a mere accident of convoluted
__eq__-vs-__cmp__ code paths in the comparison code.
In other words, there is no chance to get the 2.4 behavior
in, say, Python 3000, because the __cmp__-related
convolutions will be gone and we will only have the "right"
behavior left.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 11:13
Message:
Logged In: YES
user_id=38388
In any case, the introduction of the Unicode tp_richcompare
slot is likely the cause for this behavior:
$python2.5 lowerstr.py
u'baR' == l'Bar'? False
$ python2.4 lowerstr.py
u'baR' == l'Bar'? True
Note that in both Python 2.4 and 2.5, the lowerstr.__eq__()
method is not even called. This is probably due to the fact
that Unicode can compare itself to strings, so the
w.__eq__(v) part of the rich comparison is never tried.
Now, the Unicode .__eq__() converts the string to Unicode,
so the right hand side becomes u'Bar' in both cases.
I guess a debugger session is due...
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 10:55
Message:
Logged In: YES
user_id=38388
Ah, wrong track: Py_TPFLAGS_HAVE_RICHCOMPARE is set via
Py_TPFLAGS_DEFAULT.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 10:39
Message:
Logged In: YES
user_id=38388
Armin, is it possible that the missing
Py_TPFLAGS_HAVE_RICHCOMPARE type flag in the Unicode type is
causing this ?
I just had a look at the code and it appears that the
comparison code checks the flag rather than just looking at
the slot itself (didn't even know there was such a type flag).
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-25 21:33
Message:
Logged In: YES
user_id=4771
Sorry, I missed your comment: if lowerstr inherits from
unicode then it just works. The reason is that
'abc'.__eq__(u'abc') returns NotImplemented, but
u'abc'.__eq__('abc') returns True.
This is only inconsistent because of the asymmetry between
strings and unicodes: strings can be transparently turned
into unicodes but not the other way around -- so
unicode.__eq__(x) can accept a string as the argument x
and convert it to a unicode transparently, but str.__eq__(x)
does not try to convert x to a string if it is a unicode.
It's not a completely convincing explanation, but I think it
shows at least why we got at the current situation of Python
2.5.
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-25 21:11
Message:
Logged In: YES
user_id=4771
This is an artifact of the change in the unicode class, which
now has the proper __eq__, __ne__, __lt__, etc. methods
instead of the semi-deprecated __cmp__. The mixture of
__cmp__ and the other methods is not very well-defined. This
is why your code worked in 2.4: a bit by chance.
Indeed, in theory it should not, according to the language
reference. So what I am saying is that although it is a
behavior change from 2.4 to 2.5, I would argue that it is not
a bug but a bug fix...
The reason is that if we ignore the __eq__ vs __cmp__ issues,
the operation 'a == b' is defin
[ python-Bugs-1564763 ] Unicode comparison change in 2.4 vs. 2.5
Bugs item #1564763, was opened at 2006-09-25 01:43
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1564763&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: Unicode
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode comparison change in 2.4 vs. 2.5
Initial Comment:
Python 2.5 changed the behavior of unicode comparisons
in a significant way from Python 2.4, causing a test
case failure in a module of mine. All tests passed with
an earlier version of 2.5, though unfortunately I don't
know what version in particular it started failing with.
The following code prints out all True on Python 2.4;
the strings are compared case-insensitively, whether
they are my lowerstr class, real strs, or unicodes. On
Python 2.5, the comparison between lowerstr and unicode
is false, but only in one direction.
If I make lowerstr inherit from unicode rather than
str, all comparisons are true again. So at the very
least, this is internally inconsistent. I also think
changing the behavior between 2.4 and 2.5 constitutes a
serious bug.
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-27 12:22
Message:
Logged In: YES
user_id=38388
Agreed.
In Python 2.4, doing the u'baR' == l'Bar' comparison does
try l'Bar' == u'baR' due to the special case in
default_3way_compare() I removed for Python 2.5.
In Python 2.5 it doesn't due to the new rich comparison code
for Unicode.
I don't see any way to make Joe's code work with Python 2.5
other than using unicode as baseclass which is probably the
right things to do anyway in preparation for Python 3k.
Closing as won't fix.
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-27 10:58
Message:
Logged In: YES
user_id=4771
Well, yes, that's what I tried to explain. I also tried to
explain how the 2.5 behavior is the "right" one, and the
previous 2.4 behavior is a mere accident of convoluted
__eq__-vs-__cmp__ code paths in the comparison code.
In other words, there is no chance to get the 2.4 behavior
in, say, Python 3000, because the __cmp__-related
convolutions will be gone and we will only have the "right"
behavior left.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 13:13
Message:
Logged In: YES
user_id=38388
In any case, the introduction of the Unicode tp_richcompare
slot is likely the cause for this behavior:
$python2.5 lowerstr.py
u'baR' == l'Bar'? False
$ python2.4 lowerstr.py
u'baR' == l'Bar'? True
Note that in both Python 2.4 and 2.5, the lowerstr.__eq__()
method is not even called. This is probably due to the fact
that Unicode can compare itself to strings, so the
w.__eq__(v) part of the rich comparison is never tried.
Now, the Unicode .__eq__() converts the string to Unicode,
so the right hand side becomes u'Bar' in both cases.
I guess a debugger session is due...
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 12:55
Message:
Logged In: YES
user_id=38388
Ah, wrong track: Py_TPFLAGS_HAVE_RICHCOMPARE is set via
Py_TPFLAGS_DEFAULT.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-09-26 12:39
Message:
Logged In: YES
user_id=38388
Armin, is it possible that the missing
Py_TPFLAGS_HAVE_RICHCOMPARE type flag in the Unicode type is
causing this ?
I just had a look at the code and it appears that the
comparison code checks the flag rather than just looking at
the slot itself (didn't even know there was such a type flag).
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-25 23:33
Message:
Logged In: YES
user_id=4771
Sorry, I missed your comment: if lowerstr inherits from
unicode then it just works. The reason is that
'abc'.__eq__(u'abc') returns NotImplemented, but
u'abc'.__eq__('abc') returns True.
This is only inconsistent because of the asymmetry between
strings and unicodes: strings can be transparently turned
into unicodes but not the other way around -- so
unicode.__eq__(x) can accept a string as the argument x
and convert it to a unicode transparently, but str.__eq__(x)
does not try to convert x to a string if it is a unicode.
It's not a completely convincing explanation, but I think it
shows at least why we got at the current situation of Python
2.5.
--
Comment By: Armin Rigo (arigo)
Date: 2006-09-25 23:
[ python-Bugs-1563079 ] code.InteractiveConsole() and closed sys.stdout
Bugs item #1563079, was opened at 2006-09-21 13:53 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563079&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: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: code.InteractiveConsole() and closed sys.stdout Initial Comment: This code raises a ValueError: import code c = code.InteractiveConsole() c.interact() import sys sys.stdout.close() because the InteractiveConsole uses raw_input() to display its prompt. I'm not sure where the correct place to fix this is. One possible way is to allow raw_input() to take optional arguments to use instead of sys.stdin and sys.stdout. Another (easier?) way to fix this problem might be to beef up InteractiveConsole.raw_input() a bit. I'm open to either option, but I think InteractiveConsole needs to continue working even if the user closes sys.stdout. This applies to the 2.4 and 2.5 branches as well as the trunk. -- >Comment By: Skip Montanaro (montanaro) Date: 2006-09-27 05:46 Message: Logged In: YES user_id=44345 Here's a plausible (I think) patch for code.InteractiveConsole. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563079&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-1566260 ] Better order in file type descriptions
Feature Requests item #1566260, was opened at 2006-09-27 11:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1566260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Nobody/Anonymous (nobody) Summary: Better order in file type descriptions Initial Comment: Hello, just a little idea i apply each time i install a new Python version on Windows. When files extensions are registered, ".py" extension receives the description "Python File", while ".pyc", ".pyo" are described as "Compiled Python File". This means that, when files are shown into an Explorer window and sorted by file type, the compiled files appear above the source files, while usually an user wants to work with sources. I usually change the file description to "Python file - compiled", so that i can have the sources before the .pyc's and in alphabetical order. A bonus would be to have .pyw file appear before sources, because they are supposed to be double-clicked and having them at the top could be handy. They may be described as "No Console Python File", for example. my € 0.02 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1566260&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566280 ] Logging problem on Windows XP
Bugs item #1566280, was opened at 2006-09-27 14:49 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=1566280&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: Pavel Krupets (pavel_krupets) Assigned to: Nobody/Anonymous (nobody) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566280 ] Logging problem on Windows XP
Bugs item #1566280, was opened at 2006-09-27 14:49 Message generated for change (Comment added) made by pavel_krupets You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&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: Pavel Krupets (pavel_krupets) Assigned to: Nobody/Anonymous (nobody) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. -- >Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 15:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC005: Access violation reading location 0x0034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://
[ python-Bugs-1565071 ] update Lib/plat-linux2/IN.py
Bugs item #1565071, was opened at 2006-09-25 14:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565071&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: update Lib/plat-linux2/IN.py Initial Comment: there's a request to update this module to add missing IN.SIO* definitions. How should that be done? Just re-running h2py drops all SIO* definitions, because the linux/sockios.h header isn't included anymore. requested at http://launchpad.net/bugs/58081 -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-27 14:08 Message: Logged In: YES user_id=21627 It's convention that plat-* mirrors the structure of the header files. So ISTM that we should add sockios.py; IN.py should perhaps be regenerated only a release later. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565071&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566331 ] Bad behaviour in .obuf*
Bugs item #1566331, was opened at 2006-09-27 13:19 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=1566331&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sam Dennis (samdennis) Assigned to: Nobody/Anonymous (nobody) Summary: Bad behaviour in .obuf* Initial Comment: The _ssize() function in ossaudiodev.c (2.4.3, but it's the same in svn) calls SNDCTL_SET_CHANNELS with channels=0 as part of an attempt to determine the total number of samples per second for the current configuration of the audio device, but as far as I can tell this is not guaranteed to act as a query and at least two implementations treat it as a request for a monaural format (the ALSA pcm-oss module and the alsa-oss library). What this can safely be replaced with I don't know; both Linux's OSS drivers and ALSA support SOUND_PCM_READ_CHANNELS but this is not standard to the best of my knowledge. Storing the value returned when the program calls .setfmt or .setparameters may be an option. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566331&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566602 ] test_posixpath failure
Bugs item #1566602, was opened at 2006-09-27 16: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=1566602&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: WallsRSolid (wallsrsolid)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_posixpath failure
Initial Comment:
On a compile from the Python 2.5 Final tarball in Linux
on a 64-bit, dual Opteron system, "make test" reports
one failure:
test test_posixpath failed -- Traceback (most recent
call last):
File
"/archive/home/nvf/temp/Python-2.5/Lib/test/test_posixpath.py",
line 353, in test_expanduser
posixpath.expanduser("~/")
AssertionError: '/archive/home/nvf//' !=
'/archive/home/nvf/'
In searching the bug database, I see that failures used
to happen on Tru64 and MacOS9, but there was no mention
of failure on a Linux system.
Versions:
python -V: Python 2.5
gcc -v:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada
--enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566602&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566611 ] Idle 2.1 - Calltips Hotkey dies not work
Bugs item #1566611, was opened at 2006-09-27 22:24 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=1566611&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: fladd (fladd710) Assigned to: Nobody/Anonymous (nobody) Summary: Idle 2.1 - Calltips Hotkey dies not work Initial Comment: Hitting CTRL+Backslash does not show the calltip (which is not shown by default) on Windows Xp with Python 1.5 Final. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566611 ] Idle 2.1 - Calltips Hotkey does not work
Bugs item #1566611, was opened at 2006-09-27 22:24 Message generated for change (Settings changed) made by fladd710 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: fladd (fladd710) Assigned to: Nobody/Anonymous (nobody) >Summary: Idle 2.1 - Calltips Hotkey does not work Initial Comment: Hitting CTRL+Backslash does not show the calltip (which is not shown by default) on Windows Xp with Python 1.5 Final. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566611 ] Idle 1.2 - Calltips Hotkey does not work
Bugs item #1566611, was opened at 2006-09-27 22:24 Message generated for change (Settings changed) made by fladd710 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: fladd (fladd710) Assigned to: Nobody/Anonymous (nobody) >Summary: Idle 1.2 - Calltips Hotkey does not work Initial Comment: Hitting CTRL+Backslash does not show the calltip (which is not shown by default) on Windows Xp with Python 1.5 Final. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory
Bugs item #1565525, was opened at 2006-09-26 06:58 Message generated for change (Comment added) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. -- >Comment By: Greg Hazel (ghazel) Date: 2006-09-27 21:07 Message: Logged In: YES user_id=731668 The bug is the circular reference which is non-obvious and unavoidable, and cleaned up at some uncontrolable (unless you run a full collection) time in the future. There are many better situations or solutions to this bug, depending on which you think it is. I think those should be investigated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-27 07:49 Message: Logged In: YES user_id=21627 I'm still having problems figuring out what the bug is that you are reporting. Ok, in this case, it consumes a lot of memory. Why is that a bug? -- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 03:20 Message: Logged In: YES user_id=731668 I have read the exc_info suggestions before, but they have never made any difference. Neither change you suggest modifies the memory footprint behaviour in any way. Weakrefs might be slow, I offered them as an alternative to just removing the references entirely. I understand this might cause problems with existing code, but the current situation causes a problem which is more difficult to work around. Code that needs locals and globals can explicity store a reference to eat - it is impossible to dig in to the traceback object and remove those references. The use-case of storing the exc_info is fairly simple, for example: Two threads. One queues a task for the other to complete. That task fails an raises an exception. The exc_info is caught, passed back to the first thread, the exc_info is raised from there. The goal is to get the whole execution stack, which it does quite nicely, except that it has this terrible memory side effect. -- Comment By: Tim Peters (tim_one) Date: 2006-09-26 10:04 Message: Logged In: YES user_id=31435 Your memory bloat is mostly due to the d = range(10) line. Python has no problem collecting the cyclic trash, but you're creating 10 * 100 = 10 million integer objects hanging off trash cycles before invoking gc.collect(), and those integers require at least 10 million * 12 ~= 120MB all by themselves. Worse, memory allocated to "short" integers is both immortal and unbounded: it can be reused for /other/ integer objects, but it never goes away. Note that memory usage in your program remains low and steady if you force gc.collect() after every call to bar(). Then you only create 100K integers, instead of 10M, before the trash gets cleaned up. There is no simple-minded way to "repair" this, BTW. For example, /of course/ a frame has to reference all its locals, and moving to weak references for those instead would be insanely inefficient (among other, and deeper, problems). Note that
[ python-Bugs-1566663 ] Library Reference Section 5.1.8.1 is wrong.
Bugs item #153, was opened at 2006-09-27 17:52 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=153&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Chris Connett (cconnett) Assigned to: Nobody/Anonymous (nobody) Summary: Library Reference Section 5.1.8.1 is wrong. Initial Comment: The examples section of the datetime doc is out of date. The example says that the datetime class doesn't support strptime directly, but as of Python 2.5, it does. I think the whole example is obsolete, and should probably be deleted. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=153&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566719 ] site-packages isn't created before install_egg_info
Bugs item #1566719, was opened at 2006-09-27 21:34 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=1566719&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: James Oakley (jfunk) Assigned to: Nobody/Anonymous (nobody) Summary: site-packages isn't created before install_egg_info Initial Comment: install_egg_info is called without creating the site-packages directory when only a script is specified. This can break RPM builds since the site-packages directory isn't present beforehand. Here's an setup.py that causes this problem:: from distutils.core import setup setup(name='dot2tex', version='1.0.1', description = 'A Graphviz to LaTeX converter', author = 'Kjell Magne Fauske', author_email = '[EMAIL PROTECTED]', url = "http://www.fauskes.net/code/dot2tex/";, download_url = "http://www.fauskes.net/code/dot2tex/download/";, scripts=['dot2tex/dot2tex.py'] ) Here's the build output:: + python setup.py install --prefix=/usr --root=/var/tmp/dot2tex-buildroot --record=INSTALLED_FILES running install running build running build_scripts running install_scripts creating /var/tmp/dot2tex-buildroot creating /var/tmp/dot2tex-buildroot/usr creating /var/tmp/dot2tex-buildroot/usr/bin copying build/scripts-2.5/dot2tex.py -> /var/tmp/dot2tex-buildroot/usr/bin changing mode of /var/tmp/dot2tex-buildroot/usr/bin/dot2tex.py to 755 running install_egg_info Writing /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info error: /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info: No such file or directory -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory
Bugs item #1565525, was opened at 2006-09-26 08:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-28 05:03 Message: Logged In: YES user_id=21627 I disagree that the circular reference is non-obvious. I'm not sure what your application is, but I would expect that callers of sys.exc_info should be fully aware what a traceback is, and how it refers to the current frames. I do agree that it is unavoidable; I fail to see that it is a bug because of that (something unavoidable cannot be a bug). If you are saying that it is unavoidable in your application: I have difficulties believing this. For example, you could do s.e = sys.exc_info()[:2] This would drop the traceback, and thus not create a cyclic reference. Since, in the program you present, the traceback is never used, this looks like a "legal" simplification (of course, you don't use s.e at all in this program, so I can only guess that you don't need the traceback in your real application). As for the time of cleanup not being controllable: you can certainly control frequency of gc with gc.set_threshold; no need to invoke gc explicitly. tim_one: Why do you think your proposed modification of introducing get_traceback would help? The frame foo still refers to s (which is an O), and s.e will still refer to the traceback that includes foo. -- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 23:07 Message: Logged In: YES user_id=731668 The bug is the circular reference which is non-obvious and unavoidable, and cleaned up at some uncontrolable (unless you run a full collection) time in the future. There are many better situations or solutions to this bug, depending on which you think it is. I think those should be investigated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-27 09:49 Message: Logged In: YES user_id=21627 I'm still having problems figuring out what the bug is that you are reporting. Ok, in this case, it consumes a lot of memory. Why is that a bug? -- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 05:20 Message: Logged In: YES user_id=731668 I have read the exc_info suggestions before, but they have never made any difference. Neither change you suggest modifies the memory footprint behaviour in any way. Weakrefs might be slow, I offered them as an alternative to just removing the references entirely. I understand this might cause problems with existing code, but the current situation causes a problem which is more difficult to work around. Code that needs locals and globals can explicity store a reference to eat - it is impossible to dig in to the traceback object and remove those references. The use-case of storing the exc_info is fairly simple, for example: Two threads. One queues a task for the other to complete.
[ python-Bugs-1566719 ] site-packages isn't created before install_egg_info
Bugs item #1566719, was opened at 2006-09-28 02:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: James Oakley (jfunk) Assigned to: Nobody/Anonymous (nobody) Summary: site-packages isn't created before install_egg_info Initial Comment: install_egg_info is called without creating the site-packages directory when only a script is specified. This can break RPM builds since the site-packages directory isn't present beforehand. Here's an setup.py that causes this problem:: from distutils.core import setup setup(name='dot2tex', version='1.0.1', description = 'A Graphviz to LaTeX converter', author = 'Kjell Magne Fauske', author_email = '[EMAIL PROTECTED]', url = "http://www.fauskes.net/code/dot2tex/";, download_url = "http://www.fauskes.net/code/dot2tex/download/";, scripts=['dot2tex/dot2tex.py'] ) Here's the build output:: + python setup.py install --prefix=/usr --root=/var/tmp/dot2tex-buildroot --record=INSTALLED_FILES running install running build running build_scripts running install_scripts creating /var/tmp/dot2tex-buildroot creating /var/tmp/dot2tex-buildroot/usr creating /var/tmp/dot2tex-buildroot/usr/bin copying build/scripts-2.5/dot2tex.py -> /var/tmp/dot2tex-buildroot/usr/bin changing mode of /var/tmp/dot2tex-buildroot/usr/bin/dot2tex.py to 755 running install_egg_info Writing /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info error: /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info: No such file or directory -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-28 05:26 Message: Logged In: YES user_id=21627 How can there not be a site-packages directory? It is created with the installation of Python itself, so it is always there. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566280 ] Logging problem on Windows XP
Bugs item #1566280, was opened at 2006-09-27 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&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: Pavel Krupets (pavel_krupets) Assigned to: Nobody/Anonymous (nobody) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-28 05:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? -- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 14:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC005: Access violation reading location 0x0034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e0622d3() python25.dll!1e062660() python25.dll!1e061028() python25.dll!1e0db1bd() python25.dll!1e062676() python25.dll!1e03e8c1() python25.dll!1e041475() python25.dll!1e0414c3() python25.dll!1e094093() python25.dll!1e062676() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e033edc() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e070385() python25.dll!1e03db7d() python25.dll!1e039a8c() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e07041e() python25.dll!1e03db7d() python25.dll!1e0715df() python25.dll!1e0268ec() python25.dll!1e040a04() ntdll.dll!7c90d625() ntdll.dll!7c90eacf() python25.dll!1e0258d2() ntdll.dll!7c9105c8() ntdll.dll!7c910551() ntdll.dll!7c91056d() kernel32.dll!7c80261a() kernel32.dll!7c8025f0() kernel32.dll!7c8025f0() kernel32.dll!7c802532() python25.dll!1e0268ec() python25.dll!1e03987a() python25.dll!1e0cdf07() python25.dll!1e0cd899() msvcr71.dll!7c34940f() kernel32.dll!7c80b683() --
[ python-Bugs-1565525 ] gc allowing tracebacks to eat up memory
Bugs item #1565525, was opened at 2006-09-26 02:58 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565525&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: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: gc allowing tracebacks to eat up memory Initial Comment: Attached is a file which demonstrates an oddity about traceback objects and the gc. The observed behaviour is that when the tuple from sys.exc_info() is stored on an object which is inside the local scope, the object, thus exc_info tuple, are not collected even when both leave scope. If you run the test with "s.e = sys.exc_info()" commented out, the observed memory footprint of the process quickly approaches and sits at 5,677,056 bytes. Totally reasonable. If you uncomment that line, the memory footprint climbs to 283,316,224 bytes quite rapidly. That's a two order of magnitude difference! If you uncomment the "gc.collect()" line, the process still hits 148,910,080 bytes. This was observed in production code, where exc_info tuples are saved for re-raising later to get the stack- appending behaviour tracebacks and 'raise' perform. The example includes a large array to simulate application state. I assume this is bad behaviour occurring because the traceback object holds frames, and those frames hold a reference to the local objects, thus the exc_info tuple itself, thus causing a circular reference which involves the entire stack. Either the gc needs to be improved to prevent this from growing so wildly, or the traceback objects need to (optionally?) hold frames which do not have references or have weak references instead. -- >Comment By: Tim Peters (tim_one) Date: 2006-09-27 23:48 Message: Logged In: YES user_id=31435 [Martin] > tim_one: Why do you think your proposed modification of > introducing get_traceback would help? The frame foo still > refers to s (which is an O), and s.e will still refer > to the traceback that includes foo. Sorry about that! It was an illusion, of course. I wanted to suggest a quick fix, and "tested it" too hastily in a program that didn't actually bloat with /or/ without it. For the OP, I had need last year of capturing a traceback and (possibly) displaying it later in ZODB. It never would have occurred to me to try saving away exc_info(), though. Instead I used the `traceback` module to capture the traceback output (a string), which was (possibly) displayed later, with annotations, by a different thread. No cycles, no problems. BTW, I must repeat that there is no simple-minded way to 'repair' this. That isn't based on general principle, but on knowledge of how Python is implemented. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-27 23:03 Message: Logged In: YES user_id=21627 I disagree that the circular reference is non-obvious. I'm not sure what your application is, but I would expect that callers of sys.exc_info should be fully aware what a traceback is, and how it refers to the current frames. I do agree that it is unavoidable; I fail to see that it is a bug because of that (something unavoidable cannot be a bug). If you are saying that it is unavoidable in your application: I have difficulties believing this. For example, you could do s.e = sys.exc_info()[:2] This would drop the traceback, and thus not create a cyclic reference. Since, in the program you present, the traceback is never used, this looks like a "legal" simplification (of course, you don't use s.e at all in this program, so I can only guess that you don't need the traceback in your real application). As for the time of cleanup not being controllable: you can certainly control frequency of gc with gc.set_threshold; no need to invoke gc explicitly. tim_one: Why do you think your proposed modification of introducing get_traceback would help? The frame foo still refers to s (which is an O), and s.e will still refer to the traceback that includes foo. -- Comment By: Greg Hazel (ghazel) Date: 2006-09-27 17:07 Message: Logged In: YES user_id=731668 The bug is the circular reference which is non-obvious and unavoidable, and cleaned up at some uncontrolable (unless you run a full collection) time in the future. There are many better situations or solutions to this bug, depending on which you think it is. I think those should be investigated. -- Comment By: Martin v.
[ python-Bugs-1566800 ] urllib doesn't raise IOError correctly with new IOError
Bugs item #1566800, was opened at 2006-09-28 07:47 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=1566800&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: Arthibus Gissehel (gissehel) Assigned to: Nobody/Anonymous (nobody) Summary: urllib doesn't raise IOError correctly with new IOError Initial Comment: The version I used is : >>> sys.version '2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]' On Windows XP SP2. While I think every python 2.5 releases are concerned. On line 357 of urllib.py from 2.5 release, there is a raise of an IOError with 4 arguments. It look like it was fine with python 2.4 but it hang up with a "TypeError: EnvironmentError expected at most 3 arguments, got 4" Concretly, when you hit a page with a "redirect" using error 302 for exemple, instead of raising an IOError, it raise a TypeError, so it break code which expect an IOError here (as a "normal" behavior for 302 codes) It look like IOError is totally different between Python 2.4 and Python 2.5 (it was a class, it's now a type) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566800&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
