[ python-Bugs-1469629 ] __dict__ = self in subclass of dict causes a memory leak?
Bugs item #1469629, was opened at 2006-04-12 22:04 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469629&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dobes V (dobesv) Assigned to: Nobody/Anonymous (nobody) Summary: __dict__ = self in subclass of dict causes a memory leak? Initial Comment: Using: ActivePython 2.4.2 Build 10 (ActiveState Corp.) based on Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32 For reasons I do not understand, the following class leaks itself continuously: class AttrDict(dict): def __init__(self, *args, **kw): dict.__init__(self, *args, **kw) self.__dict__ = self Whereas this version does not: class AttrDict(dict): def __init__(self, *args, **kw): dict.__init__(self, *args, **kw) def __getattr__(self, key): return self[key] def __setattr__(self, key, value): self[key] = value My test looks like this: for n in xrange(100): import gc gc.collect() ad = AttrDict() ad['x'] = n ad.y = ad.x print n, ad.x, ad.y And I sit and watch in the windows task manager while the process grows and grows. With the __getattr__ version, it doesn't grow. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-14 00:19 Message: Logged In: YES user_id=33168 Armin, why not just check any leaking test cases into Lib/test/leakers? I have no idea if your patch is correct or not. I wouldn't be surprised if there are a bunch more issues similar to this. What if you stick self in self.__dict__ (I'm guessing this is ok, but there are a bunch of variations) or start playing with weakrefs? -- Comment By: Armin Rigo (arigo) Date: 2006-04-13 02:58 Message: Logged In: YES user_id=4771 This is caused by the tp_clear not doing its job -- in this case, tp_clear is subtype_clear(), which does not reset the __dict__ slot to NULL because it assumes that the __dict__ slot's content itself will be cleared, which is perfectly true but doesn't help if self.__dict__ is self. Attached a patch to fix this. It's kind of hard to test for this bug because all instances of AttrDict are really cleared, weakrefs to them are removed, etc. Also attached is an example showing a similar bug: a cycle through the ob_type field, with a object U whose class is itself. It is harder to clear this link because we cannot just set ob_type to NULL in subtype_clear. Ideas welcome... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469629&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470212 ] mailbox.PortableUnixMailbox fails to parse 'From ' in body
Bugs item #1470212, was opened at 2006-04-13 20:35 Message generated for change (Comment added) made by hdiwan650 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470212&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: Lars Kellogg-Stedman (larsks) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox.PortableUnixMailbox fails to parse 'From ' in body Initial Comment: I have a Unix mailbox file that contains the following text in the body of a message: ---[ cut here ]--- EFCO also offers casements with integral blinds. See:=20 http://www.efcocorp.com/public/earm/products/default.asp?j=3D1&P=3D43&L=3D= 1=20 >From that page, select select "Features and Benefits" from under the heading "Product Overview"=20 ---[ cut here ]--- mailbox.PortableUnixMailbox erroneously interprets the "From" at the beginning of the line as the beginning of a new message. Since 'From ' is only a valid header at the beginning of a message, perhaps the module could look at the following line and see if it looks like an RFC2822 header before accepting 'From ' as a message delimiter. -- Comment By: Hasan Diwan (hdiwan650) Date: 2006-04-14 01:30 Message: Logged In: YES user_id=1185570 Use rfc822.py in lieu of mailbox to first parse the message into an rfc822.Message... then pass it to the Mailbox.PortableUnixMailbox constructor. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470212&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467929 ] %-formatting and dicts
Bugs item #1467929, was opened at 2006-04-10 12:39
Message generated for change (Comment added) made by hdiwan650
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: %-formatting and dicts
Initial Comment:
This looks like a bug in the way the %-formatting code
works or is it a feature ?
>>> '%s %(a)s' % {'a': 'xyz'}
"{'a': 'xyz'} xyz"
>>> u'%s %(a)s' % {'a': 'xyz'}
u"{'a': 'xyz'} xyz"
Note that both strings and Unicode are affected.
Python 2.3 and 2.4 also show this behavior.
I would have expected an exception or the %-formatter
simply ignoring the first %s.
--
Comment By: Hasan Diwan (hdiwan650)
Date: 2006-04-14 01:33
Message:
Logged In: YES
user_id=1185570
It looks as though it's a feature... The first %s will print
the whole dictionary as a string, the second, only that
value looked up by the key.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470300 ] QNX4.25 port
Bugs item #1470300, was opened at 2006-04-14 18:04
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=1470300&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: kbob_ru (kbob_ru)
Assigned to: Nobody/Anonymous (nobody)
Summary: QNX4.25 port
Initial Comment:
In QNX4.25 there is no and rusage.
I used next patch to compile _hotshot.c module in
QNX4.25 wuth Watcom10.6 compiler.
*** /usr/local/src/Python-2.4.3.orig/Modules/_hotshot.c
Mon Mar 20 16:37:16 2006
--- /usr/local/src/Python-2.4.3/Modules/_hotshot.c
Sat Apr 15 17:16:47 2006
***
*** 26,32
#ifndef HAVE_GETTIMEOFDAY
#error "This module requires gettimeofday() on non-
Windows platforms!"
#endif
! #if (defined(PYOS_OS2) && defined(PYCC_GCC))
#include
#else
#include
--- 26,32
#ifndef HAVE_GETTIMEOFDAY
#error "This module requires gettimeofday() on non-
Windows platforms!"
#endif
! #if (defined(PYOS_OS2) && defined(PYCC_GCC)) ||
defined(__QNX__)
#include
#else
#include
***
*** 917,923
#endif
}
#if defined(MS_WINDOWS) || defined(PYOS_OS2) || \
! defined(__VMS)
rusage_diff = -1;
#else
{
--- 917,923
#endif
}
#if defined(MS_WINDOWS) || defined(PYOS_OS2) || \
! defined(__VMS) || defined (__QNX__)
rusage_diff = -1;
#else
{
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470300&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470300 ] QNX4.25 port
Bugs item #1470300, was opened at 2006-04-14 18:04
Message generated for change (Comment added) made by kbob_ru
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470300&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: kbob_ru (kbob_ru)
Assigned to: Nobody/Anonymous (nobody)
Summary: QNX4.25 port
Initial Comment:
In QNX4.25 there is no and rusage.
I used next patch to compile _hotshot.c module in
QNX4.25 wuth Watcom10.6 compiler.
*** /usr/local/src/Python-2.4.3.orig/Modules/_hotshot.c
Mon Mar 20 16:37:16 2006
--- /usr/local/src/Python-2.4.3/Modules/_hotshot.c
Sat Apr 15 17:16:47 2006
***
*** 26,32
#ifndef HAVE_GETTIMEOFDAY
#error "This module requires gettimeofday() on non-
Windows platforms!"
#endif
! #if (defined(PYOS_OS2) && defined(PYCC_GCC))
#include
#else
#include
--- 26,32
#ifndef HAVE_GETTIMEOFDAY
#error "This module requires gettimeofday() on non-
Windows platforms!"
#endif
! #if (defined(PYOS_OS2) && defined(PYCC_GCC)) ||
defined(__QNX__)
#include
#else
#include
***
*** 917,923
#endif
}
#if defined(MS_WINDOWS) || defined(PYOS_OS2) || \
! defined(__VMS)
rusage_diff = -1;
#else
{
--- 917,923
#endif
}
#if defined(MS_WINDOWS) || defined(PYOS_OS2) || \
! defined(__VMS) || defined (__QNX__)
rusage_diff = -1;
#else
{
--
>Comment By: kbob_ru (kbob_ru)
Date: 2006-04-14 18:06
Message:
Logged In: YES
user_id=1347065
patch in attachment
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470300&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x
Bugs item #1470353, was opened at 2006-04-14 23:11 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=1470353&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: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1355883 ] make depend/clean issues w/ ast
Bugs item #1355883, was opened at 2005-11-13 14:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: make depend/clean issues w/ ast Initial Comment: I noticed two issues with the ast vis a vis building and cleaning. Haven't had a chance to look into them, however... 1. From a fresh checkout, execute configure, then "make -j2". It will run Parser/asdl_c.py twice simultaneously. This can obviously lead to corrupt Python-ast.[ch] files. 2. Neither "make clean" nor "make distclean" delete the Python-ast.[ch] files. "make distclean" at least should. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-14 17:04 Message: Logged In: YES user_id=21627 This was fixed with patch #1355971. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-16 22:49 Message: Logged In: YES user_id=1188172 Is that still an issue? -- Comment By: Thomas Lee (krumms) Date: 2005-11-13 17:58 Message: Logged In: YES user_id=315535 Fix for part 1 here: http://sourceforge.net/tracker/index.php?func=detail&aid=1355971&group_id=5470&atid=305470 -- Comment By: Thomas Lee (krumms) Date: 2005-11-13 17:45 Message: Logged In: YES user_id=315535 Already on it :) Shall have a patch up shortly. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-13 17:44 Message: Logged In: YES user_id=44345 I was thinking it might be something like that. Perhaps asdl_c.py should be modified to accept an output flag (--output=[hc] or -h/-c) so it only generates one file or the other. -- Comment By: Thomas Lee (krumms) Date: 2005-11-13 17:24 Message: Logged In: YES user_id=315535 The first problem is being caused by a simple misunderstanding/oversight in Makefile.pre.in. The rule for a target will be called for each target. In our case, we have Python-ast.h and Python-ast.c in our list of targets. So asdl_c.py gets called once for each target. Hope this makes sense. :) If not I can bang up a patch so you can at least see what I'm on about. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470300 ] QNX4.25 port
Bugs item #1470300, was opened at 2006-04-14 12:04
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470300&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: kbob_ru (kbob_ru)
Assigned to: Nobody/Anonymous (nobody)
Summary: QNX4.25 port
Initial Comment:
In QNX4.25 there is no and rusage.
I used next patch to compile _hotshot.c module in
QNX4.25 wuth Watcom10.6 compiler.
*** /usr/local/src/Python-2.4.3.orig/Modules/_hotshot.c
Mon Mar 20 16:37:16 2006
--- /usr/local/src/Python-2.4.3/Modules/_hotshot.c
Sat Apr 15 17:16:47 2006
***
*** 26,32
#ifndef HAVE_GETTIMEOFDAY
#error "This module requires gettimeofday() on non-
Windows platforms!"
#endif
! #if (defined(PYOS_OS2) && defined(PYCC_GCC))
#include
#else
#include
--- 26,32
#ifndef HAVE_GETTIMEOFDAY
#error "This module requires gettimeofday() on non-
Windows platforms!"
#endif
! #if (defined(PYOS_OS2) && defined(PYCC_GCC)) ||
defined(__QNX__)
#include
#else
#include
***
*** 917,923
#endif
}
#if defined(MS_WINDOWS) || defined(PYOS_OS2) || \
! defined(__VMS)
rusage_diff = -1;
#else
{
--- 917,923
#endif
}
#if defined(MS_WINDOWS) || defined(PYOS_OS2) || \
! defined(__VMS) || defined (__QNX__)
rusage_diff = -1;
#else
{
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-14 17:08
Message:
Logged In: YES
user_id=21627
Thanks for the patch. Committed as r45391.
--
Comment By: kbob_ru (kbob_ru)
Date: 2006-04-14 12:06
Message:
Logged In: YES
user_id=1347065
patch in attachment
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470300&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470422 ] Logging doesn't report the correct filename or line numbers
Bugs item #1470422, was opened at 2006-04-14 11:48 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=1470422&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: Michael Tsai (michaeltsai) Assigned to: Nobody/Anonymous (nobody) Summary: Logging doesn't report the correct filename or line numbers Initial Comment: I have a logger that prints out %(filename)s:%(lineno)d along with the message. Instead of printing the file and line in my code where I call the logger, it prints out a location in logging/__init__.py. I was able to fix this, at least for my purposes, by changing logging.currentframe from sys._getframe to lambda:sys._getframe(3). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1162001 ] configure incorrectly adds -OPT:Olimit=0 for icc
Bugs item #1162001, was opened at 2005-03-12 14:54 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162001&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific >Status: Closed Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: configure incorrectly adds -OPT:Olimit=0 for icc Initial Comment: When using Python 2.4 and the Intel C Compiler, configure adds -OPT:Olimit=0 to BASECFLAGS. This is because using icc -OPT:Olimit=0 does not produce an error, but instead an irritating warning for every source file compiled. $ icc -OPT:Olimit=0 test1.c; echo $? icc: Command line warning: ignoring option '-O'; no argument required 0 $ gcc -OPT:Olimit=0 test1.c; echo $? cc1: error: invalid option argument `-OPT:Olimit=0' 1 -- >Comment By: Michael Hoffman (hoffmanm) Date: 2006-04-14 18:35 Message: Logged In: YES user_id=987664 Supposedly fixed in r41953. -- Comment By: Michael Hoffman (hoffmanm) Date: 2005-03-12 15:58 Message: Logged In: YES user_id=987664 Patch submitted: http://sourceforge.net/tracker/index.php?func=detail&aid=1162023&group_id=5470&atid=305470 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162001&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1162001 ] configure incorrectly adds -OPT:Olimit=0 for icc
Bugs item #1162001, was opened at 2005-03-12 14:54 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162001&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: configure incorrectly adds -OPT:Olimit=0 for icc Initial Comment: When using Python 2.4 and the Intel C Compiler, configure adds -OPT:Olimit=0 to BASECFLAGS. This is because using icc -OPT:Olimit=0 does not produce an error, but instead an irritating warning for every source file compiled. $ icc -OPT:Olimit=0 test1.c; echo $? icc: Command line warning: ignoring option '-O'; no argument required 0 $ gcc -OPT:Olimit=0 test1.c; echo $? cc1: error: invalid option argument `-OPT:Olimit=0' 1 -- >Comment By: Michael Hoffman (hoffmanm) Date: 2006-04-14 18:36 Message: Logged In: YES user_id=987664 Supposedly fixed in r41953. -- Comment By: Michael Hoffman (hoffmanm) Date: 2006-04-14 18:35 Message: Logged In: YES user_id=987664 Supposedly fixed in r41953. -- Comment By: Michael Hoffman (hoffmanm) Date: 2005-03-12 15:58 Message: Logged In: YES user_id=987664 Patch submitted: http://sourceforge.net/tracker/index.php?func=detail&aid=1162023&group_id=5470&atid=305470 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1162001&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x
Bugs item #1470353, was opened at 2006-04-14 15:11 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&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: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? -- >Comment By: Thomas Heller (theller) Date: 2006-04-14 21:08 Message: Logged In: YES user_id=11105 This looks very similar to a problem I recently 'fixed' on OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86 the problem seemed to be that small structures are passed like short or int. You could try to fix it by adding the appropriate definition in Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines 138. Maybe changing them to #if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__NetBSD__) or whatever the magic symbol for Netbsd is. Unfortunately I do not have access to a netbsd machine myself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x
Bugs item #1470353, was opened at 2006-04-14 15:11 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&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: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? -- >Comment By: Thomas Heller (theller) Date: 2006-04-14 21:09 Message: Logged In: YES user_id=11105 Of course I meant FreeBSD instead of NetBSD, sorry. -- Comment By: Thomas Heller (theller) Date: 2006-04-14 21:08 Message: Logged In: YES user_id=11105 This looks very similar to a problem I recently 'fixed' on OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86 the problem seemed to be that small structures are passed like short or int. You could try to fix it by adding the appropriate definition in Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines 138. Maybe changing them to #if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__NetBSD__) or whatever the magic symbol for Netbsd is. Unfortunately I do not have access to a netbsd machine myself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470502 ] Mention coercion removal in Misc/NEWS
Bugs item #1470502, was opened at 2006-04-14 12: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=1470502&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 3000 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) Summary: Mention coercion removal in Misc/NEWS Initial Comment: Neal has been ripping out __coerce__ but Misc/NEWS doesn't mention that. Should be mentioned (along with test_coercion being removed). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470502&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470508 ] Error in PyGen_NeedsFinalizing()
Bugs item #1470508, was opened at 2006-04-14 15:31
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=1470508&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: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Phillip J. Eby (pje)
Summary: Error in PyGen_NeedsFinalizing()
Initial Comment:
There's an off-by-one error in PyGen_NeedsFinalizing():
the loop starts by looking at
f->f_blockstack[f->f_iblock], but that's one beyond the
largest legitimate f_blockstack index. As a result,
any generator with an active loop is very likely to
claim it needs finalizing (to the extent that it's
unlikely that reading up trash for b_type will match
SETUP_LOOP).
The attached patch repairs that, but also tries to
remove some of the goofy .close() gimmicks added to old
tests in test_generators to worm around "leaks" caused
by that all generators said they needed finalizers in
2.5 at first. (That's how I bumped into this: I tried
removing the .close() gimmicks first, but -R:: runs
said they still leaked -- that started the trail
leading to PyGen_NeedsFinalizing()).
Alas, after applying the patch, test_generators craps
out in a debug build with a NULL-pointer dereference in
_Py_ForgetReference(), in the guts of the `if` test
deciding whether to produce an "UNREF invalid object"
error. At the time, op_type is _PyGen_Type and
op->_ob_next = _ob_prev = NULL, probably meaning that
op was already passed to _Py_ForgetReference() previously.
We get into _Py_ForgetReference() via a chain starting
at the the decref in ceval.c's
while (STACK_LEVEL() > b->b_level) {
v = POP();
Py_XDECREF(v);
and we got into PyEval_EvalFrameEx via gen_send_ex via
gen_close via gen_dealloc via (eventually) a dict on
some instance going away ... and then I got lost.
Looks like there are several more layers of generator
deallocs on the call stack too.
I'm out of time for looking at this now, so recording
it here.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470508&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470540 ] XMLGenerator creates a mess with UTF-16
Bugs item #1470540, was opened at 2006-04-15 00:07 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=1470540&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: Open Resolution: None Priority: 5 Submitted By: Nikolai Grigoriev (ngrig) Assigned to: Nobody/Anonymous (nobody) Summary: XMLGenerator creates a mess with UTF-16 Initial Comment: When output encoding in xml.sax.saxutils.XMLGenerator is set to UTF-16, the result is a terrible mess. Namely: - it does not encode the XML declaration at the very top of the file (leaving it in single-byte Latin); - it leaves closing '>' of each start tag unencoded (that is, always outputs a single byte); - it inserts a spurious byte order mark for each tag, each attribute, each text node, and each processing instruction. A test illustrating the issue is attached. The issue is applicable to both stable (2.4.3) and current (2.5) versions of Python. - Looking in xml/sax/saxutils.py, I see the problem in XMLGenerator._write(): - one-byte strings aren't recoded at all (sic!); - two-byte strings are converted using unicode.encode(); this results in a BOM for each call of _write() on Unicode strings. The issue is easy to fix by using StreamWriter instead of a plain stream as the output sink. I am going to submit a patch shortly. Regards, Nikolai Grigoriev -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470540&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x
Bugs item #1470353, was opened at 2006-04-14 15:11 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&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: Andrew I MacIntyre (aimacintyre) >Assigned to: Thomas Heller (theller) Summary: test_ctypes fails on FreeBSD 4.x Initial Comment: $ ./python Lib/test/regrtest.py test_ctypes test_ctypes test test_ctypes failed -- Traceback (most recent call last): File "/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py", line 333, in test_struct_return_2H self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3)) AssertionError: (-1004, 2123) != (198, 264) 1 test failed: test_ctypes [41158 refs] This is with a subversion checkout updated to 5am AEST (Aust) 14Apr06, debug build. The returned tuple values (s2h.x, s2h.y) appear to vary from run to run, so it looks like something isn't where its expected. This is with a FreeBSD 4.8 i386 system (not particularly recent), using gcc 2.95.4. A quick and dirty test (in C) suggests that its not an alignment issue for the 2 shorts in the S2H struct. Ideas for trying to debug this further? -- Comment By: Thomas Heller (theller) Date: 2006-04-14 21:09 Message: Logged In: YES user_id=11105 Of course I meant FreeBSD instead of NetBSD, sorry. -- Comment By: Thomas Heller (theller) Date: 2006-04-14 21:08 Message: Logged In: YES user_id=11105 This looks very similar to a problem I recently 'fixed' on OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86 the problem seemed to be that small structures are passed like short or int. You could try to fix it by adding the appropriate definition in Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines 138. Maybe changing them to #if !defined(X86_WIN32) && !defined(__OpenBSD__) && !defined(__NetBSD__) or whatever the magic symbol for Netbsd is. Unfortunately I do not have access to a netbsd machine myself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470508 ] Error in PyGen_NeedsFinalizing()
Bugs item #1470508, was opened at 2006-04-14 21:31
Message generated for change (Comment added) made by twouters
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470508&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: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Phillip J. Eby (pje)
Summary: Error in PyGen_NeedsFinalizing()
Initial Comment:
There's an off-by-one error in PyGen_NeedsFinalizing():
the loop starts by looking at
f->f_blockstack[f->f_iblock], but that's one beyond the
largest legitimate f_blockstack index. As a result,
any generator with an active loop is very likely to
claim it needs finalizing (to the extent that it's
unlikely that reading up trash for b_type will match
SETUP_LOOP).
The attached patch repairs that, but also tries to
remove some of the goofy .close() gimmicks added to old
tests in test_generators to worm around "leaks" caused
by that all generators said they needed finalizers in
2.5 at first. (That's how I bumped into this: I tried
removing the .close() gimmicks first, but -R:: runs
said they still leaked -- that started the trail
leading to PyGen_NeedsFinalizing()).
Alas, after applying the patch, test_generators craps
out in a debug build with a NULL-pointer dereference in
_Py_ForgetReference(), in the guts of the `if` test
deciding whether to produce an "UNREF invalid object"
error. At the time, op_type is _PyGen_Type and
op->_ob_next = _ob_prev = NULL, probably meaning that
op was already passed to _Py_ForgetReference() previously.
We get into _Py_ForgetReference() via a chain starting
at the the decref in ceval.c's
while (STACK_LEVEL() > b->b_level) {
v = POP();
Py_XDECREF(v);
and we got into PyEval_EvalFrameEx via gen_send_ex via
gen_close via gen_dealloc via (eventually) a dict on
some instance going away ... and then I got lost.
Looks like there are several more layers of generator
deallocs on the call stack too.
I'm out of time for looking at this now, so recording
it here.
--
>Comment By: Thomas Wouters (twouters)
Date: 2006-04-15 01:22
Message:
Logged In: YES
user_id=34209
As explained on python-dev, I believe this patch fixes the
crash. It still leaves test_generators leaking 255
references, though, which I find completely unsurprising
given the pain it's caused so far :) I do believe these
changes are correct even if we don't fix the generator
leakage, but someone with more fundamental knowledge of the
cyclic GC might want to pronounce.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470508&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470508 ] Error in PyGen_NeedsFinalizing()
Bugs item #1470508, was opened at 2006-04-14 15:31
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470508&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: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Tim Peters (tim_one)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Error in PyGen_NeedsFinalizing()
Initial Comment:
There's an off-by-one error in PyGen_NeedsFinalizing():
the loop starts by looking at
f->f_blockstack[f->f_iblock], but that's one beyond the
largest legitimate f_blockstack index. As a result,
any generator with an active loop is very likely to
claim it needs finalizing (to the extent that it's
unlikely that reading up trash for b_type will match
SETUP_LOOP).
The attached patch repairs that, but also tries to
remove some of the goofy .close() gimmicks added to old
tests in test_generators to worm around "leaks" caused
by that all generators said they needed finalizers in
2.5 at first. (That's how I bumped into this: I tried
removing the .close() gimmicks first, but -R:: runs
said they still leaked -- that started the trail
leading to PyGen_NeedsFinalizing()).
Alas, after applying the patch, test_generators craps
out in a debug build with a NULL-pointer dereference in
_Py_ForgetReference(), in the guts of the `if` test
deciding whether to produce an "UNREF invalid object"
error. At the time, op_type is _PyGen_Type and
op->_ob_next = _ob_prev = NULL, probably meaning that
op was already passed to _Py_ForgetReference() previously.
We get into _Py_ForgetReference() via a chain starting
at the the decref in ceval.c's
while (STACK_LEVEL() > b->b_level) {
v = POP();
Py_XDECREF(v);
and we got into PyEval_EvalFrameEx via gen_send_ex via
gen_close via gen_dealloc via (eventually) a dict on
some instance going away ... and then I got lost.
Looks like there are several more layers of generator
deallocs on the call stack too.
I'm out of time for looking at this now, so recording
it here.
--
>Comment By: Tim Peters (tim_one)
Date: 2006-04-14 22:28
Message:
Logged In: YES
user_id=31435
Phillip checked in a related patch that looked good, fixed
the segfaults, and allowed to get rid of the explicit closes
in the LazyList-based examples without new leaking. (The
tee-based examples still need explicit closing to avoid
leaking, and I added XXX comments about that.) So, closing
as fixed.
Thanks!
--
Comment By: Thomas Wouters (twouters)
Date: 2006-04-14 19:22
Message:
Logged In: YES
user_id=34209
As explained on python-dev, I believe this patch fixes the
crash. It still leaves test_generators leaking 255
references, though, which I find completely unsurprising
given the pain it's caused so far :) I do believe these
changes are correct even if we don't fix the generator
leakage, but someone with more fundamental knowledge of the
cyclic GC might want to pronounce.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470508&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
