[ python-Bugs-1369116 ] freeze idle-python2.3 on my debia n sarge
Bugs item #1369116, was opened at 2005-11-29 13:37 Message generated for change (Comment added) made by gsantonja You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Santonja (gsantonja) Assigned to: Nobody/Anonymous (nobody) Summary: freeze idle-python2.3 on my debia n sarge Initial Comment: When I press space bar continusly idle-python task have a random freeze 8/10 times before the caracter 300. I must kill the task and restart This arrive frequently during my development. Architecture : idle python 2.3 Debian sarge without modification XFCE 4.0 Nvidia driver hp nx9105 I have try to made again the bug on other architecture but i don't have success on windows XP and debion in virtual pc. -- >Comment By: Gabriel Santonja (gsantonja) Date: 2005-12-14 13:02 Message: Logged In: YES user_id=1392073 Hello, > What happens when you start IDLE with no subprocess > (use the > -n switch)? The same thing : freeze 4 time on 5 test. > time IDLE will freeze. Correct? yes. idle freeze spécially when i use the space caracters for indentation. -- Comment By: Kurt B. Kaiser (kbk) Date: 2005-12-14 07:06 Message: Logged In: YES user_id=149084 What happens when you start IDLE with no subprocess (use the -n switch)? You say it happens frequently in development. I assume that you mean that in normal use after typing for some time IDLE will freeze. Correct? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Bugs item #1153075, was opened at 2005-02-27 21:55 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&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: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro Initial Comment: The functions PyInt_Check(), PyString_Check(), PyList_Check() etc. are used all over the core to check which typecasts are safe, from PyObject* to the various PyXxxObject*. But the macros themselves are implemented by inspecting the "tp_mro" tuple of the incoming object's type. As the latter can be completely controlled by the user, an object can pretend to inherit from anything and pass the PyXxx_Check() checks of its choice, even if its memory layout is actually completely wrong. See attached example. -- >Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:41 Message: Logged In: YES user_id=4771 I'm getting confused. First note that the problem I mentioned about extra_ivars() triggering an assert() can only occur at start-up. Indeed, PyType_Ready() copies the tp_base->tp_basicsize if the subtype's tp_basicsize is 0. So we can probably ignore the problem -- no extra_ivars() call would trigger the assert after start-up. The check that your patch adds is that solid_base(A) must be a superclass of solid_base(T) for each A in the mro of T. For built-in mros, the A's are exactly the superclasses of T. So we have to prove [*]: if A is a superclass of T, then solid_base(A) is a superclass of solid_base(T). Irrespective of what extra_ivars() does, solid_base(T) is either exactly T, or solid_base(T->tp_base). Moreover, when a type T is created with immediate bases B1...Bn, we check that all solid_bases of B1...Bn form a linear order (i.e. are subclasses of each other), and we set T->tp_base to the first Bi such that solid_base(Bi) is a subclass of all the other solid_base(Bj). Let's approach [*] above by induction on the set of types in which A and T are chosen. This set of types can be ordered by creation time: T1, T2, T3, ... where classes with a higher index can only inherit from classes with lower indices. Assume that [*] holds if A and T are chosen among T1...Tn-1. Let's prove it if A and/or T can also be Tn. The only non-trivial case is if A is a strict superclass of T=Tn. As above, let write B1...Bn for the immediate bases of T, with T->tp_base=Bi. Pick j such that A is a superclass of Bj. By induction solid_base(A) is a superclass of solid_base(Bj) which is a superclass of solid_base(Bi=T->tp_base). Now solid_base(T) is either T or solid_base(Bi). In both cases, solid_base(T) is a subclass of solid_base(A). This concludes the proof -- or I am missing something :-) In other words, I don't think the patch can break anything, so it should definitely go in. -- Comment By: Michael Hudson (mwh) Date: 2005-03-15 13:22 Message: Logged In: YES user_id=6656 Please see the attached PDF for a proof of ... well, something in the area. I think this is what typeobject.c should be doing and what it's *trying* to do. I'm less confident that this is what it's actually doing (particularly wrt the subclassing two subclasses of str thing). -- Comment By: Michael Hudson (mwh) Date: 2005-03-14 11:41 Message: Logged In: YES user_id=6656 Well, emprically that can't happen because the patch passes test_descr, and far sillier things happen in that file than in real life. More theoretically... I'll think about it :) -- Comment By: Armin Rigo (arigo) Date: 2005-03-14 11:25 Message: Logged In: YES user_id=4771 I tried to convince myself that this check always accepts the default mro, but there are more implicit assumptions around than I can handle in a quick review... Instead, I modified the patch so that a debug build of Python always does the check in mro_internal(). This results in a shallow problem: the basestring type has tp_basicsize==0, which makes the computation of its solid_base trigger an assertion in extra_ivars(). If I hack around this problem, then I cannot quickly find an example of built-in mro that triggers a TypeError, but it doesn't mean there isn't one... -- Comment By: Michael Hudson (mwh) Date: 2005-03-06 18:47 Message: Logged In: YES user_id=6656 I think the attached fixes all this. What it does:
[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&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: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. -- >Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:49 Message: Logged In: YES user_id=4771 Uh oh. There is a much simpler crash. The technique outlined in deldict.py can be used to rebind or even delete the __dict__ attribute of instances where it should normally not be allowed. -- Comment By: Armin Rigo (arigo) Date: 2005-09-25 08:55 Message: Logged In: YES user_id=4771 The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup which are not careful about the reference counters of the objects they operate on. This allows a much simpler crash (test67.py): the __dict__ of an object can be decrefed away while lookdict() is looking at it. This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in core routines like PyObject_GenericGetAttr. We probably need to measure if it has a performance impact, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1174712 ] subclassing ModuleType and another built-in type
Bugs item #1174712, was opened at 2005-04-01 09:22
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174712&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: subclassing ModuleType and another built-in type
Initial Comment:
class X(types.ModuleType, str): pass
X('name')
-> segfault
This buggy subclassing goes through typeobject.c's checks because
PyModuleObject looks exactly like a user-defined subclass of 'object': it has a
PyObject_HEAD followed only by the dict, as specified by tp_dictoffset.
A fix would be to forbid any subclassing to move the tp_dictoffset of a
non-heap type.
--
>Comment By: Armin Rigo (arigo)
Date: 2005-12-14 14:57
Message:
Logged In: YES
user_id=4771
The objection to the proposed fix is not valid in light
of the bug #1303614, which gives a general way to abuse
subclassing to allow the __dict__ of an instance to be
assigned to and deleted, even when it should not be allowed. So I wouldn't
worry too much about the case I pointed up, because it should be fixed together
with #1303614 (though I don't really know how). For now I would be happy with
just checking that subclassing a non-heap type doesn't move the dict within the
structure.
The same remark probably applies to the weakref field. Both cases could be
fixed by being more careful in typeobject.c:extra_ivars(): PyModule_Type should
be considered to have extra_ivars() when compared to PyBaseObject_Type. This
could be achieved by skipping the "t_size -= ..." part if "type" is not a heap
type. Indeed, for non-heap types we should not try to consider that an extra
dict or weakref slot is not important, because the C code probably accesses
this extra slot directly, as in the case of moduleobject.c.
--
Comment By: Michael Hudson (mwh)
Date: 2005-04-03 13:39
Message:
Logged In: YES
user_id=6656
> This might point to the need for cleaning up typeobject.c's
> darker corners...
No kidding. Maybe Samuele, you and I can gang up on Guido at
EuroPython (is he sprinting? Perhaps we should ask).
--
Comment By: Armin Rigo (arigo)
Date: 2005-04-02 12:27
Message:
Logged In: YES
user_id=4771
The proposed fix is not good enough. If another built-in C type similar to
PyModuleObject is defined (say by a C extension module), then it would become
possible to subclass both this new type and ModuleType. This might lead to
unwanted behavior if e.g. one parent class allows rebinding __dict__ and the
other not (and crashes if __dict__ is rebound).
This might point to the need for cleaning up typeobject.c's darker corners...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174712&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&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: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. -- >Comment By: Armin Rigo (arigo) Date: 2005-12-14 15:32 Message: Logged In: YES user_id=4771 A proposed fix for the later crash: the __dict__ descriptor of user-defined classes should verify if there is another __dict__ descriptor along the solid path of the type (i.e. following "tp_base" pointers). If so, it should delegate to it. -- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:49 Message: Logged In: YES user_id=4771 Uh oh. There is a much simpler crash. The technique outlined in deldict.py can be used to rebind or even delete the __dict__ attribute of instances where it should normally not be allowed. -- Comment By: Armin Rigo (arigo) Date: 2005-09-25 08:55 Message: Logged In: YES user_id=4771 The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup which are not careful about the reference counters of the objects they operate on. This allows a much simpler crash (test67.py): the __dict__ of an object can be decrefed away while lookdict() is looking at it. This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in core routines like PyObject_GenericGetAttr. We probably need to measure if it has a performance impact, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Bugs item #1303614, was opened at 2005-09-25 00:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&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: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. -- >Comment By: Michael Hudson (mwh) Date: 2005-12-14 15:36 Message: Logged In: YES user_id=6656 Yikes! -- Comment By: Armin Rigo (arigo) Date: 2005-12-14 15:32 Message: Logged In: YES user_id=4771 A proposed fix for the later crash: the __dict__ descriptor of user-defined classes should verify if there is another __dict__ descriptor along the solid path of the type (i.e. following "tp_base" pointers). If so, it should delegate to it. -- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:49 Message: Logged In: YES user_id=4771 Uh oh. There is a much simpler crash. The technique outlined in deldict.py can be used to rebind or even delete the __dict__ attribute of instances where it should normally not be allowed. -- Comment By: Armin Rigo (arigo) Date: 2005-09-25 09:55 Message: Logged In: YES user_id=4771 The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup which are not careful about the reference counters of the objects they operate on. This allows a much simpler crash (test67.py): the __dict__ of an object can be decrefed away while lookdict() is looking at it. This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in core routines like PyObject_GenericGetAttr. We probably need to measure if it has a performance impact, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1353269 ] poplib.POP3_SSL() class incompatible with socket.timeout
Bugs item #1353269, was opened at 2005-11-10 17:34 Message generated for change (Comment added) made by arekm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Nobody/Anonymous (nobody) Summary: poplib.POP3_SSL() class incompatible with socket.timeout Initial Comment: If you call socket.setdefaulttimeout() to enable timeout mode, then create a POP3-over-SSL connection by instantiating a poplib.POP3_SSL() object, the resulting connection can hang because the underlying socket.ssl() object doesn't work when timeouts are enabled. If, after creating the POP3_SSL object, you call object.conn.sock.setblocking(1), the hangs will not happen. This is exactly the same bug as happened with IMAP SSL connections, as I reported in bug #977680. The Python documentation still does not mention that socket SSL support is not compatible with socket timeout support. -- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-12-14 23:59 Message: Logged In: YES user_id=139606 It's just broken in _ssl.c. In PySSL_SSLread() there is: sockstate = check_socket_and_wait_for_timeout(self->Socket, 0); It hangs here because that function waits for new data on the socket but SSL layer could already read that data. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1353269 ] poplib.POP3_SSL() class incompatible with socket.timeout
Bugs item #1353269, was opened at 2005-11-10 17:34 Message generated for change (Comment added) made by arekm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Nobody/Anonymous (nobody) Summary: poplib.POP3_SSL() class incompatible with socket.timeout Initial Comment: If you call socket.setdefaulttimeout() to enable timeout mode, then create a POP3-over-SSL connection by instantiating a poplib.POP3_SSL() object, the resulting connection can hang because the underlying socket.ssl() object doesn't work when timeouts are enabled. If, after creating the POP3_SSL object, you call object.conn.sock.setblocking(1), the hangs will not happen. This is exactly the same bug as happened with IMAP SSL connections, as I reported in bug #977680. The Python documentation still does not mention that socket SSL support is not compatible with socket timeout support. -- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-12-15 00:31 Message: Logged In: YES user_id=139606 btw. please test this patch: https://sourceforge.net/tracker /index.php?func=detail&aid=1380952&group_id=5470&atid=305470 -- Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-12-14 23:59 Message: Logged In: YES user_id=139606 It's just broken in _ssl.c. In PySSL_SSLread() there is: sockstate = check_socket_and_wait_for_timeout(self->Socket, 0); It hangs here because that function waits for new data on the socket but SSL layer could already read that data. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1380970 ] split() description not fully accurate
Bugs item #1380970, was opened at 2005-12-14 18:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&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.4 Status: Open Resolution: None Priority: 5 Submitted By: K.C. (kace) Assigned to: Nobody/Anonymous (nobody) Summary: split() description not fully accurate Initial Comment: The page http://docs.python.org/lib/string-methods.html reads, in part, "If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends." However, this is not the behaviour that I'm seeing. (Although, I should note that I'd find the described behaviour more desirable.) Example, >>> trow = '1586\tsome-int-name\tNODES: 111_222\n' >>> print trow 1234some-int-name NODES: 111_222 >>> trow.split(None,2) ['1234', 'some-int-name', 'NODES: 111_222\n'] # end example. Notice that the trailing newline has not been stripped as the documentation said it should be. Thanks all. K.C. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1380970 ] split() description not fully accurate
Bugs item #1380970, was opened at 2005-12-14 18:33 Message generated for change (Comment added) made by kace You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&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.4 Status: Open Resolution: None Priority: 5 Submitted By: K.C. (kace) Assigned to: Nobody/Anonymous (nobody) Summary: split() description not fully accurate Initial Comment: The page http://docs.python.org/lib/string-methods.html reads, in part, "If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends." However, this is not the behaviour that I'm seeing. (Although, I should note that I'd find the described behaviour more desirable.) Example, >>> trow = '1586\tsome-int-name\tNODES: 111_222\n' >>> print trow 1234some-int-name NODES: 111_222 >>> trow.split(None,2) ['1234', 'some-int-name', 'NODES: 111_222\n'] # end example. Notice that the trailing newline has not been stripped as the documentation said it should be. Thanks all. K.C. -- >Comment By: K.C. (kace) Date: 2005-12-14 18:36 Message: Logged In: YES user_id=741142 Also, (oops) the example comes from the most recent version: $ python Python 2.4.2 (#2, Oct 4 2005, 13:57:10) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1369116 ] freeze idle-python2.3 on my debia n sarge
Bugs item #1369116, was opened at 2005-11-29 07:37 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Gabriel Santonja (gsantonja) >Assigned to: Kurt B. Kaiser (kbk) Summary: freeze idle-python2.3 on my debia n sarge Initial Comment: When I press space bar continusly idle-python task have a random freeze 8/10 times before the caracter 300. I must kill the task and restart This arrive frequently during my development. Architecture : idle python 2.3 Debian sarge without modification XFCE 4.0 Nvidia driver hp nx9105 I have try to made again the bug on other architecture but i don't have success on windows XP and debion in virtual pc. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-12-14 19:27 Message: Logged In: YES user_id=149084 Ok, this looks like a duplicate of Bug 1108992. It appears to be a Tcl bug or maybe a pthread bug. Refer to the gdb trace attached to that bug. There's nothing I can do in IDLE, which is pure Python. I suggest you make sure you are apt-get upgraded and if the problem persists, either try Python from Sid or submit a Debian bug. -- Comment By: Gabriel Santonja (gsantonja) Date: 2005-12-14 07:02 Message: Logged In: YES user_id=1392073 Hello, > What happens when you start IDLE with no subprocess > (use the > -n switch)? The same thing : freeze 4 time on 5 test. > time IDLE will freeze. Correct? yes. idle freeze spécially when i use the space caracters for indentation. -- Comment By: Kurt B. Kaiser (kbk) Date: 2005-12-14 01:06 Message: Logged In: YES user_id=149084 What happens when you start IDLE with no subprocess (use the -n switch)? You say it happens frequently in development. I assume that you mean that in normal use after typing for some time IDLE will freeze. Correct? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1380970 ] split() description not fully accurate
Bugs item #1380970, was opened at 2005-12-14 18:33 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&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.4 Status: Open Resolution: None Priority: 5 Submitted By: K.C. (kace) >Assigned to: Raymond Hettinger (rhettinger) Summary: split() description not fully accurate Initial Comment: The page http://docs.python.org/lib/string-methods.html reads, in part, "If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends." However, this is not the behaviour that I'm seeing. (Although, I should note that I'd find the described behaviour more desirable.) Example, >>> trow = '1586\tsome-int-name\tNODES: 111_222\n' >>> print trow 1234some-int-name NODES: 111_222 >>> trow.split(None,2) ['1234', 'some-int-name', 'NODES: 111_222\n'] # end example. Notice that the trailing newline has not been stripped as the documentation said it should be. Thanks all. K.C. -- Comment By: K.C. (kace) Date: 2005-12-14 18:36 Message: Logged In: YES user_id=741142 Also, (oops) the example comes from the most recent version: $ python Python 2.4.2 (#2, Oct 4 2005, 13:57:10) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1380970&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1361643 ] textwrap.dedent() expands tabs
Bugs item #1361643, was opened at 2005-11-19 14:02
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&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: 6
Submitted By: Steven Bethard (bediviere)
Assigned to: Greg Ward (gward)
Summary: textwrap.dedent() expands tabs
Initial Comment:
I'm not sure whether this is a documentation bug or a
code bug, but textwrap.dedent() expands tabs (and
AFAICT doesn't give the user any way of stopping this):
py> def test():
... x = ('abcdefgh\n'
... 'ijklmnop\n')
... y = textwrap.dedent('''... abcdefgh
... ijklmnop
... ''')
... return x, y
...
py> test()
('abcd\tefgh\nijkl\tmnop\n', 'abcdefgh\nijkl
mnop\n')
Looking at the code, I can see the culprit is the first
line:
lines = text.expandtabs().split('\n')
If this is the intended behavior, I think the first
sentence in the documentation[1] should be replaced with:
"""
Replace all tabs in string with spaces as per
str.expandtabs() and then remove any whitespace that
can be uniformly removed from the left of every line in
text.
"""
and (I guess this part is an RFE) textwrap.dedent()
should gain an optional expandtabs= keyword argument to
disable this behavior.
If it's not the intended behavior, I'd love to see that
.expandtabs() call removed.
[1]http://docs.python.org/lib/module-textwrap.html
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-20 01:04
Message:
Logged In: YES
user_id=80475
Suggested code:
import re as _re
_emptylines_with_spaces = _re.compile('(?m)^[ \t]+$')
_prefixes_on_nonempty_lines = _re.compile('(?m)(^[
\t]*)(?:[^ \t\n]+)')
def dedent(text):
text = _emptylines_with_spaces.sub('', text)
prefixes = _prefixes_on_nonempty_lines.findall(text)
margin = min(prefixes or [''])
if margin:
text = _re.sub('(?m)^' + margin, '', text)
return text
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-19 23:52
Message:
Logged In: YES
user_id=80475
After more thought, I think the expandtabs() is a bug since
it expands content tabs as well as margin tabs:
>>> textwrap.dedent('\tABC\t\tDEF')
'ABC DEF'
This is especially problematic given that dedent() has to
guess at the tab size.
If this gets fixed, I recommend using regular expressions as
a way to indentify common margin prefixes on non-empty
lines. This will also mixes of spaces and tabs without
altering content with embedded tabs and without making
assumptions about the tab size. Also, it ought to run
somewhat faster.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-19 15:18
Message:
Logged In: YES
user_id=80475
FWIW, the tab expansion would be more useful if the default
tabsize could be changed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376775 ] Memory leak in the email package
Bugs item #1376775, was opened at 2005-12-08 17:03
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ken668 (ken668)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Memory leak in the email package
Initial Comment:
memory leak in email.message_from_string. This is what
I did to create a leak.
You used the attached file, memleak.eml.
f = open("memleak.eml")
buffer = f.read()
f.close()
# now buffer has the email string
msg = email.message_from_string(buffer)
msg = None # this should free the memory but it doesn't
# The memory that is used in msg is not completely free
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-14 21:56
Message:
Logged In: YES
user_id=33168
Do you still believe there is a problem or can this report
be closed?
--
Comment By: ken668 (ken668)
Date: 2005-12-12 08:00
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 07:59
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 07:53
Message:
Logged In: YES
user_id=1400763
I added these three lines after the line "msg=None"
import gc
print "gc.collect()\n\n", gc.collect()
print "gc.garbage\n\n", gc.garbage
If you pipe the output of gc.garbage to a file, you will see
the email message you just sent are still be in the memory.
Everytime I call email.message_from_string, a copy of the
message will be kept in the memory even after I set the
returned value to None.
I tried the same thing with email package email-2.5.tar.gz,
that memory was freed right after I set the variable "msg"
to None.
Thanks
Ken
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-11 12:13
Message:
Logged In: YES
user_id=33168
What causes you to believe this is a memory leak? I ran
this under valgrind and it doesn't report any leaks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs
Bugs item #1377858, was opened at 2005-12-10 13:20 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Nobody/Anonymous (nobody) Summary: segfaults when using __del__ and weakrefs Initial Comment: You can segfault Python by creating a weakref to an object in its __del__ method, storing it somewhere and then trying to dereference the weakref afterwards. the attached file shows the described behaviour. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file
Bugs item #1378755, was opened at 2005-12-12 06:24
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Didrik Pinte (dpinte)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging : fileConfig does not check existance of the file
Initial Comment:
Hi,
The fileConfig method from the logging.config module
does not check for the existance of the config file
before trying to load it.
Worst, if the file does not exist, the exception is
totally unrelated to the file.
Example :
[EMAIL PROTECTED]:~/$ python
Python 2.3.5 (#2, Nov 20 2005, 16:40:39)
[GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> from logging import config
>>> config.fileConfig('')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/logging/config.py", line 68,
in fileConfig
flist = cp.get("formatters", "keys")
File "/usr/lib/python2.3/ConfigParser.py", line 505,
in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'formatters'
It is really important that the exception is correctly
reported.
In fact, the problem seems to be here :
/usr/lib/python2.3/ConfigParser.py, line 258
for filename in filenames:
try:
fp = open(filename)
except IOError:
continue
self._read(fp, filename)
The documentation of the read method says "Files that
cannot be opened are silently ignored;".
The behaviour of logging.config.fileConfig is highly
related to the user actions. He must be informed of the
fact that the logging system have not opened its file.
I will provide a very basic path :
File /usr/lib/python2.3/logging/config.py, line 61
-
import os
if not (os.path.file(fname)):
raise IOError('Provided filename is not existing')
-
Didrik
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-14 21:58
Message:
Logged In: YES
user_id=33168
Vinay, any comments?
--
Comment By: Didrik Pinte (dpinte)
Date: 2005-12-12 06:27
Message:
Logged In: YES
user_id=970259
Oups, the patch should be the following :
File /usr/lib/python2.3/logging/config.py, line 61
-
import os
if not (os.path.isfile(fname)):
raise IOError('Provided filename is not existing')
--
Comment By: Didrik Pinte (dpinte)
Date: 2005-12-12 06:25
Message:
Logged In: YES
user_id=970259
i've reported it for Python 2.4 but I reproduced it on
Python 2.3.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378022 ] source utf8
Bugs item #1378022, was opened at 2005-12-10 22:48 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&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: 7 Submitted By: zhao (ibear) Assigned to: Nobody/Anonymous (nobody) Summary: source utf8 Initial Comment: winxp sp2(chinese or japanese) and python 2.42 i have created a utf8 source file with BOM_UTF8 if i add a '#coding: utf8' at first line and run it, the python interpreter will crash -- Comment By: Walter Dörwald (doerwalter) Date: 2005-12-12 06:35 Message: Logged In: YES user_id=89016 The following patch (pythonrun.diff) should fix the segfault. However UTF-8 files with a leading BOM currently aren't supported. There's a pending patch (http://bugs.python.org/1177307) that adds a utf-8-sig codec for that. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1373161 ] r41552 broke test_file on OS X
Bugs item #1373161, was opened at 2005-12-04 16:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373161&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: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: r41552 broke test_file on OS X Initial Comment: Apparently you *can* seek on sys.stdin here. If you just want seek() to fail sys.stdin.seek(-1) seems pretty likely to work... -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 22:07 Message: Logged In: YES user_id=33168 Michael, I reverted the tell() portion. Do all the tests work for you now? Can this be closed? -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-05 21:59 Message: Logged In: YES user_id=33168 Sorry, I think I closed the report before I saw that there was another problem. From a man page, it looked like tell() may fail if it is done on a pipe. So maybe the problem can't happen on OS X? We could check if the system is osx/darwin and skip the test. Do you want to skip the test? Since it was for coverage and to ensure nothing bad goes wrong with error handling, it's not awful that it can't be provoked on osx. -- Comment By: Michael Hudson (mwh) Date: 2005-12-05 01:31 Message: Logged In: YES user_id=6656 I suspect you know this from what I said on IRC, but test_file still fails, because you can tell() on sys.stdin too (I don't really see what you can do about this) -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-04 17:17 Message: Logged In: YES user_id=33168 revision 41602 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1373161&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376775 ] Memory leak in the email package
Bugs item #1376775, was opened at 2005-12-08 17:03
Message generated for change (Comment added) made by ken668
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ken668 (ken668)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Memory leak in the email package
Initial Comment:
memory leak in email.message_from_string. This is what
I did to create a leak.
You used the attached file, memleak.eml.
f = open("memleak.eml")
buffer = f.read()
f.close()
# now buffer has the email string
msg = email.message_from_string(buffer)
msg = None # this should free the memory but it doesn't
# The memory that is used in msg is not completely free
--
>Comment By: ken668 (ken668)
Date: 2005-12-14 22:44
Message:
Logged In: YES
user_id=1400763
Yes, it is a bug. My mistake was when I gave the details, I
should have mentioned gc.get_objects(), not gc.garbage.
gc.get_objects() showed the leaks not gc.garbage.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-14 21:56
Message:
Logged In: YES
user_id=33168
Do you still believe there is a problem or can this report
be closed?
--
Comment By: ken668 (ken668)
Date: 2005-12-12 08:00
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 07:59
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 07:53
Message:
Logged In: YES
user_id=1400763
I added these three lines after the line "msg=None"
import gc
print "gc.collect()\n\n", gc.collect()
print "gc.garbage\n\n", gc.garbage
If you pipe the output of gc.garbage to a file, you will see
the email message you just sent are still be in the memory.
Everytime I call email.message_from_string, a copy of the
message will be kept in the memory even after I set the
returned value to None.
I tried the same thing with email package email-2.5.tar.gz,
that memory was freed right after I set the variable "msg"
to None.
Thanks
Ken
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-11 12:13
Message:
Logged In: YES
user_id=33168
What causes you to believe this is a memory leak? I ran
this under valgrind and it doesn't report any leaks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
