[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 15:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Neal Norwitz (nnorwitz) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 09:04 Message: Logged In: YES user_id=21627 Originator: NO dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but I still cannot reproduce the problem... -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 06:38 Message: Logged In: YES user_id=33168 Originator: NO I screwed up the first checkin. The CLEAR_DBT was in the wrong place. The fixes are in: Committed revision 55452. Committed revision 55454. (2.5) -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 05:54 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report David. It would be great if you could test the change. I couldn't find any other places that had a similar problem, but you never know. You will need to pull out of SVN. It's a one line change if you want to apply manually. Committed revision 55450. Committed revision 55451. (2.5) -- Comment By: David Favor (dfavor) Date: 2007-05-18 23:26 Message: Logged In: YES user_id=370230 Originator: YES The os I'm running is Fedora 6 with latest patches. gcc is 4.1.1 glibc is 2.5 I had to set MALLOC_CHECK_=1 just to get the suite to run as normal MALLOC_CHECK_ defaults to die when something evil occurs. I'll build gcc 4.2, rebuild and see what occurs. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 23:02 Message: Logged In: YES user_id=849994 Originator: NO I don't even need to set an environment variable to get ~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3 test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x0827874c *** [1]17141 abort ./python Lib/test/regrtest.py -uall test_bsddb3 (HEAD, linux x86, gcc 4.1.2, glibc 2.5) -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 19:43 Message: Logged In: YES user_id=21627 Originator: NO Unfortunately, I cannot reproduce this problem on Debian unstable (x86, gcc 4.1.3, glibc 2.5) - the test passes just fine with _MALLOC_CHECK set. Can you provide a few more details: glibc version, compiler version, Linux distribution, processor architecture, precise Python version being test, does the error happen on the first or a subsequent cycle of all tests? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 15:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Neal Norwitz (nnorwitz) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 09:08 Message: Logged In: YES user_id=21627 Originator: NO (I'm not convinced that Neal's patch could actually fix anything) Can people who were able to reproduce this please report their bdb version also; I was using 4.4. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 09:04 Message: Logged In: YES user_id=21627 Originator: NO dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but I still cannot reproduce the problem... -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 06:38 Message: Logged In: YES user_id=33168 Originator: NO I screwed up the first checkin. The CLEAR_DBT was in the wrong place. The fixes are in: Committed revision 55452. Committed revision 55454. (2.5) -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 05:54 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report David. It would be great if you could test the change. I couldn't find any other places that had a similar problem, but you never know. You will need to pull out of SVN. It's a one line change if you want to apply manually. Committed revision 55450. Committed revision 55451. (2.5) -- Comment By: David Favor (dfavor) Date: 2007-05-18 23:26 Message: Logged In: YES user_id=370230 Originator: YES The os I'm running is Fedora 6 with latest patches. gcc is 4.1.1 glibc is 2.5 I had to set MALLOC_CHECK_=1 just to get the suite to run as normal MALLOC_CHECK_ defaults to die when something evil occurs. I'll build gcc 4.2, rebuild and see what occurs. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 23:02 Message: Logged In: YES user_id=849994 Originator: NO I don't even need to set an environment variable to get ~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3 test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x0827874c *** [1]17141 abort ./python Lib/test/regrtest.py -uall test_bsddb3 (HEAD, linux x86, gcc 4.1.2, glibc 2.5) -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 19:43 Message: Logged In: YES user_id=21627 Originator: NO Unfortunately, I cannot reproduce this problem on Debian unstable (x86, gcc 4.1.3, glibc 2.5) - the test passes just fine with _MALLOC_CHECK set. Can you provide a few more details: glibc version, compiler version, Linux distribution, processor architecture, precise Python version being test, does the error happen on the first or a subsequent cycle of all tests? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 13:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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.5 >Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Neal Norwitz (nnorwitz) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 10:31 Message: Logged In: YES user_id=849994 Originator: NO I can confirm that the checkin didn't change anything for me. I use bsddb version 4.5.20_p2 from Gentoo. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 07:08 Message: Logged In: YES user_id=21627 Originator: NO (I'm not convinced that Neal's patch could actually fix anything) Can people who were able to reproduce this please report their bdb version also; I was using 4.4. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 07:04 Message: Logged In: YES user_id=21627 Originator: NO dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but I still cannot reproduce the problem... -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 04:38 Message: Logged In: YES user_id=33168 Originator: NO I screwed up the first checkin. The CLEAR_DBT was in the wrong place. The fixes are in: Committed revision 55452. Committed revision 55454. (2.5) -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 03:54 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report David. It would be great if you could test the change. I couldn't find any other places that had a similar problem, but you never know. You will need to pull out of SVN. It's a one line change if you want to apply manually. Committed revision 55450. Committed revision 55451. (2.5) -- Comment By: David Favor (dfavor) Date: 2007-05-18 21:26 Message: Logged In: YES user_id=370230 Originator: YES The os I'm running is Fedora 6 with latest patches. gcc is 4.1.1 glibc is 2.5 I had to set MALLOC_CHECK_=1 just to get the suite to run as normal MALLOC_CHECK_ defaults to die when something evil occurs. I'll build gcc 4.2, rebuild and see what occurs. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 21:02 Message: Logged In: YES user_id=849994 Originator: NO I don't even need to set an environment variable to get ~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3 test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x0827874c *** [1]17141 abort ./python Lib/test/regrtest.py -uall test_bsddb3 (HEAD, linux x86, gcc 4.1.2, glibc 2.5) -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 17:43 Message: Logged In: YES user_id=21627 Originator: NO Unfortunately, I cannot reproduce this problem on Debian unstable (x86, gcc 4.1.3, glibc 2.5) - the test passes just fine with _MALLOC_CHECK set. Can you provide a few more details: glibc version, compiler version, Linux dist
[ python-Bugs-1721372 ] emphasize iteration volatility for set
Bugs item #1721372, was opened at 2007-05-18 10:10 Message generated for change (Comment added) made by aisaac0 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: emphasize iteration volatility for set Initial Comment: For http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph. Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program. *Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.) -- >Comment By: Alan (aisaac0) Date: 2007-05-19 08:09 Message: Logged In: YES user_id=1025672 Originator: YES The previous comment completely misses the point. Again, please see the discussion on c.l.python. Not one of the participants expected sets to be "ordered". What was suprising to them was the order can *change* across sequential executions of an **unchanged** source. This is of course *quite* different than expecting that sets are ordered; I am perplexed that anyone would conflate the two. One cannot credibly argue that anyone who understands that sets are not ordered will not be surprised, since even sophisticated users were as a matter of fact surprised in the c.l.python discussion. (Until it was explained by Peter of course.) A natural conclusion is that the docs should offer better protection against such surprise, since we have concrete evidence that even sophisticated users can be surprised by this. In sum, the previous comment conflates two distinct issues and so fails to address the reasons for the proposed docs patch. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 01:38 Message: Logged In: YES user_id=21627 Originator: NO The documentation already says "Being an unordered collection, sets do not record element position or order of insertion." If users read this and fail to understand the notion of an unordered collection, I see no way of "fixing" this. -- Comment By: Alan (aisaac0) Date: 2007-05-18 21:28 Message: Logged In: YES user_id=1025672 Originator: YES While I do not mind my language being rejected, *something* should be added to warn users. What the previous comment fails to mention is the number of people on c.l.python, some of whom are quite sophisticated users, who failed to discover the source of indeterminacy. Users should not have to "rediscover" this because of a documentation failure. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-18 18:08 Message: Logged In: YES user_id=80475 Originator: NO While the OP knows what he means here, the suggested text does not add clarity, it only makes the subject harder to understand and implies that some mysterious, dark force is in place. Further, the suggested text is simply incorrect. Given deterministic assignment of hash values and a consistent insertion order, the order of keys in a set or dictionary is fully determined. I've read the source of this suggestion on comp.lang.python and commented there. The underlying issue had nothing to do with either sets or dicts. The code in question "re-discovered" that the location of objects in memory would vary between runs if the user deleted a pyc file for a module. The OP's script used object ids as hash values, hence the set/dict ordering could vary between runs. This was at odds with his expectation that that the ordering would be deterministic. The moral is that non-deterministic hash values lead to non-deterministic set/dict ordering. The docs for sets and dicts should not be muddled with tangential discussions about implementation specific details regarding what governs where objects are placed in memory. -- Comment By: Alan (aisaac0) Date: 2007-05-18 13:00 Message: Logged In: YES user_id=1025672 Originator: YES Location in memory. See Peter Otten's discussion at http://www.thescripts.com/forum/post2552380-16.html -- Comment By: Martin v. Löwis
[ python-Bugs-1721812 ] A subclass of set doesn't always have __init__ called.
Bugs item #1721812, was opened at 2007-05-19 10:03 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=1721812&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 Private: No Submitted By: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: A subclass of set doesn't always have __init__ called. Initial Comment: Consider the following code: >>> class foo(set): ... def __init__(self, iter): ... print "foo.__init__" ... set.__init__(self, iter) ... >>> x = foo([1,2]) foo.__init__ >>> y = foo([2,3]) foo.__init__ >>> x & y foo([2]) As you can see, the foo.__and__ method creates a new foo object without calling foo.__init__. The problem is in Objects/setobject.c:make_new_set(). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 08:42 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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.5 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Neal Norwitz (nnorwitz) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: David Favor (dfavor) Date: 2007-05-19 10:04 Message: Logged In: YES user_id=370230 Originator: YES My test was done with latest BerkeleyDB 4.5.20 plain (no patches). -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 05:31 Message: Logged In: YES user_id=849994 Originator: NO I can confirm that the checkin didn't change anything for me. I use bsddb version 4.5.20_p2 from Gentoo. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 02:08 Message: Logged In: YES user_id=21627 Originator: NO (I'm not convinced that Neal's patch could actually fix anything) Can people who were able to reproduce this please report their bdb version also; I was using 4.4. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 02:04 Message: Logged In: YES user_id=21627 Originator: NO dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but I still cannot reproduce the problem... -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 23:38 Message: Logged In: YES user_id=33168 Originator: NO I screwed up the first checkin. The CLEAR_DBT was in the wrong place. The fixes are in: Committed revision 55452. Committed revision 55454. (2.5) -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 22:54 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report David. It would be great if you could test the change. I couldn't find any other places that had a similar problem, but you never know. You will need to pull out of SVN. It's a one line change if you want to apply manually. Committed revision 55450. Committed revision 55451. (2.5) -- Comment By: David Favor (dfavor) Date: 2007-05-18 16:26 Message: Logged In: YES user_id=370230 Originator: YES The os I'm running is Fedora 6 with latest patches. gcc is 4.1.1 glibc is 2.5 I had to set MALLOC_CHECK_=1 just to get the suite to run as normal MALLOC_CHECK_ defaults to die when something evil occurs. I'll build gcc 4.2, rebuild and see what occurs. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 16:02 Message: Logged In: YES user_id=849994 Originator: NO I don't even need to set an environment variable to get ~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3 test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x0827874c *** [1]17141 abort ./python Lib/test/regrtest.py -uall test_bsddb3 (HEAD, linux x86, gcc 4.1.2, glibc 2.5) -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 12:43 Message: Logged In: YES user_
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 08:42 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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.5 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Neal Norwitz (nnorwitz) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: David Favor (dfavor) Date: 2007-05-19 10:05 Message: Logged In: YES user_id=370230 Originator: YES Just built with latest http://svn.python.org/projects/python/branches/release25-maint pull and problem still remains. -- Comment By: David Favor (dfavor) Date: 2007-05-19 10:04 Message: Logged In: YES user_id=370230 Originator: YES My test was done with latest BerkeleyDB 4.5.20 plain (no patches). -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 05:31 Message: Logged In: YES user_id=849994 Originator: NO I can confirm that the checkin didn't change anything for me. I use bsddb version 4.5.20_p2 from Gentoo. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 02:08 Message: Logged In: YES user_id=21627 Originator: NO (I'm not convinced that Neal's patch could actually fix anything) Can people who were able to reproduce this please report their bdb version also; I was using 4.4. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 02:04 Message: Logged In: YES user_id=21627 Originator: NO dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but I still cannot reproduce the problem... -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 23:38 Message: Logged In: YES user_id=33168 Originator: NO I screwed up the first checkin. The CLEAR_DBT was in the wrong place. The fixes are in: Committed revision 55452. Committed revision 55454. (2.5) -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 22:54 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report David. It would be great if you could test the change. I couldn't find any other places that had a similar problem, but you never know. You will need to pull out of SVN. It's a one line change if you want to apply manually. Committed revision 55450. Committed revision 55451. (2.5) -- Comment By: David Favor (dfavor) Date: 2007-05-18 16:26 Message: Logged In: YES user_id=370230 Originator: YES The os I'm running is Fedora 6 with latest patches. gcc is 4.1.1 glibc is 2.5 I had to set MALLOC_CHECK_=1 just to get the suite to run as normal MALLOC_CHECK_ defaults to die when something evil occurs. I'll build gcc 4.2, rebuild and see what occurs. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 16:02 Message: Logged In: YES user_id=849994 Originator: NO I don't even need to set an environment variable to get ~/devel/python> ./python Lib/test/regrtest.py -uall test_bsddb3 test_bsddb3 *** glibc detected *** ./python: free(): inva
[ python-Bugs-1721862 ] email.FeedParser.BufferedSubFile improperly handles "\r\n"
Bugs item #1721862, was opened at 2007-05-19 11:06 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=1721862&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 Private: No Submitted By: Sye van der Veen (syeberman) Assigned to: Nobody/Anonymous (nobody) Summary: email.FeedParser.BufferedSubFile improperly handles "\r\n" Initial Comment: When email.FeedParser.BufferedSubFile sees "\r" at the end of the pushed-in data, it assumes that it is a Macintosh-style line terminator. Instead, it should request more data, to ensure that the next character is not "\n", which would make it a Windows-style line terminator. This affects email.message_from_file, which reads in the data in 8192 byte chunks. The following code demonstrates this: from StringIO import StringIO from email.FeedParser import \ BufferedSubFile, NeedMoreData fp = StringIO( "1\r\n10\r\n100\r\n" "1000\r\n1\r\n" ) bsf = BufferedSubFile( ) while True: data = fp.read( 3 ) if not data: break bsf.push( data ) for line in bsf: if line is NeedMoreData: break print repr( line ) bsf.close() The output is: '1\r\n' '10\r' '\n' '100\r\n' '1000\r\n' '1\r' '\n' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721862&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721862 ] email.FeedParser.BufferedSubFile improperly handles "\r\n"
Bugs item #1721862, was opened at 2007-05-19 11:06 Message generated for change (Comment added) made by syeberman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721862&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 Private: No Submitted By: Sye van der Veen (syeberman) Assigned to: Nobody/Anonymous (nobody) Summary: email.FeedParser.BufferedSubFile improperly handles "\r\n" Initial Comment: When email.FeedParser.BufferedSubFile sees "\r" at the end of the pushed-in data, it assumes that it is a Macintosh-style line terminator. Instead, it should request more data, to ensure that the next character is not "\n", which would make it a Windows-style line terminator. This affects email.message_from_file, which reads in the data in 8192 byte chunks. The following code demonstrates this: from StringIO import StringIO from email.FeedParser import \ BufferedSubFile, NeedMoreData fp = StringIO( "1\r\n10\r\n100\r\n" "1000\r\n1\r\n" ) bsf = BufferedSubFile( ) while True: data = fp.read( 3 ) if not data: break bsf.push( data ) for line in bsf: if line is NeedMoreData: break print repr( line ) bsf.close() The output is: '1\r\n' '10\r' '\n' '100\r\n' '1000\r\n' '1\r' '\n' -- >Comment By: Sye van der Veen (syeberman) Date: 2007-05-19 11:09 Message: Logged In: YES user_id=982447 Originator: YES File Added: BufferedSubFileBug.py -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721862&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721812 ] A subclass of set doesn't always have __init__ called.
Bugs item #1721812, was opened at 2007-05-19 14:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&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 Private: No Submitted By: David Benbennick (dbenbenn) >Assigned to: Raymond Hettinger (rhettinger) Summary: A subclass of set doesn't always have __init__ called. Initial Comment: Consider the following code: >>> class foo(set): ... def __init__(self, iter): ... print "foo.__init__" ... set.__init__(self, iter) ... >>> x = foo([1,2]) foo.__init__ >>> y = foo([2,3]) foo.__init__ >>> x & y foo([2]) As you can see, the foo.__and__ method creates a new foo object without calling foo.__init__. The problem is in Objects/setobject.c:make_new_set(). -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 16:11 Message: Logged In: YES user_id=849994 Originator: NO Wasn't that fixed some time ago? @OP: what Python version do you use? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721862 ] email.FeedParser.BufferedSubFile improperly handles "\r\n"
Bugs item #1721862, was opened at 2007-05-19 16:06 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721862&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 Private: No Submitted By: Sye van der Veen (syeberman) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.FeedParser.BufferedSubFile improperly handles "\r\n" Initial Comment: When email.FeedParser.BufferedSubFile sees "\r" at the end of the pushed-in data, it assumes that it is a Macintosh-style line terminator. Instead, it should request more data, to ensure that the next character is not "\n", which would make it a Windows-style line terminator. This affects email.message_from_file, which reads in the data in 8192 byte chunks. The following code demonstrates this: from StringIO import StringIO from email.FeedParser import \ BufferedSubFile, NeedMoreData fp = StringIO( "1\r\n10\r\n100\r\n" "1000\r\n1\r\n" ) bsf = BufferedSubFile( ) while True: data = fp.read( 3 ) if not data: break bsf.push( data ) for line in bsf: if line is NeedMoreData: break print repr( line ) bsf.close() The output is: '1\r\n' '10\r' '\n' '100\r\n' '1000\r\n' '1\r' '\n' -- Comment By: Sye van der Veen (syeberman) Date: 2007-05-19 16:09 Message: Logged In: YES user_id=982447 Originator: YES File Added: BufferedSubFileBug.py -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721862&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721812 ] A subclass of set doesn't always have __init__ called.
Bugs item #1721812, was opened at 2007-05-19 09:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&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 Private: No Submitted By: David Benbennick (dbenbenn) Assigned to: Raymond Hettinger (rhettinger) Summary: A subclass of set doesn't always have __init__ called. Initial Comment: Consider the following code: >>> class foo(set): ... def __init__(self, iter): ... print "foo.__init__" ... set.__init__(self, iter) ... >>> x = foo([1,2]) foo.__init__ >>> y = foo([2,3]) foo.__init__ >>> x & y foo([2]) As you can see, the foo.__and__ method creates a new foo object without calling foo.__init__. The problem is in Objects/setobject.c:make_new_set(). -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-19 11:25 Message: Logged In: YES user_id=80475 Originator: NO Sorry, this is just the way Python works. Given that the __and__ operation has no way of knowing the signature of your subclass contructor, it will produce a new set from your two foo inputs. This design prevades the language (for example list and int have similar behaviors). Recommend closing this as not-a-bug: >>> class foo(list): def __init__(self, iter): print 'foo.__init__' list.__init__(self, iter) >>> x = foo([1,2]) foo.__init__ >>> y = foo([2,3]) foo.__init__ >>> x + y [1, 2, 2, 3] >>> type(_) >>> >>> class foo(int): pass >>> foo(1) + foo(2) 3 >>> type(_) -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 11:11 Message: Logged In: YES user_id=849994 Originator: NO Wasn't that fixed some time ago? @OP: what Python version do you use? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721812 ] A subclass of set doesn't always have __init__ called.
Bugs item #1721812, was opened at 2007-05-19 14:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&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 Private: No Submitted By: David Benbennick (dbenbenn) Assigned to: Raymond Hettinger (rhettinger) Summary: A subclass of set doesn't always have __init__ called. Initial Comment: Consider the following code: >>> class foo(set): ... def __init__(self, iter): ... print "foo.__init__" ... set.__init__(self, iter) ... >>> x = foo([1,2]) foo.__init__ >>> y = foo([2,3]) foo.__init__ >>> x & y foo([2]) As you can see, the foo.__and__ method creates a new foo object without calling foo.__init__. The problem is in Objects/setobject.c:make_new_set(). -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 16:32 Message: Logged In: YES user_id=849994 Originator: NO There is a difference: in the list and int case, the new object is of the base type. In the set case, the new object is of type foo. But the constructor signature argument is a valid one. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-19 16:25 Message: Logged In: YES user_id=80475 Originator: NO Sorry, this is just the way Python works. Given that the __and__ operation has no way of knowing the signature of your subclass contructor, it will produce a new set from your two foo inputs. This design prevades the language (for example list and int have similar behaviors). Recommend closing this as not-a-bug: >>> class foo(list): def __init__(self, iter): print 'foo.__init__' list.__init__(self, iter) >>> x = foo([1,2]) foo.__init__ >>> y = foo([2,3]) foo.__init__ >>> x + y [1, 2, 2, 3] >>> type(_) >>> >>> class foo(int): pass >>> foo(1) + foo(2) 3 >>> type(_) -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 16:11 Message: Logged In: YES user_id=849994 Originator: NO Wasn't that fixed some time ago? @OP: what Python version do you use? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721812 ] A subclass of set doesn't always have __init__ called.
Bugs item #1721812, was opened at 2007-05-19 09:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&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 Private: No Submitted By: David Benbennick (dbenbenn) Assigned to: Raymond Hettinger (rhettinger) Summary: A subclass of set doesn't always have __init__ called. Initial Comment: Consider the following code: >>> class foo(set): ... def __init__(self, iter): ... print "foo.__init__" ... set.__init__(self, iter) ... >>> x = foo([1,2]) foo.__init__ >>> y = foo([2,3]) foo.__init__ >>> x & y foo([2]) As you can see, the foo.__and__ method creates a new foo object without calling foo.__init__. The problem is in Objects/setobject.c:make_new_set(). -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-19 11:40 Message: Logged In: YES user_id=80475 Originator: NO Hmm, that's a bummer. It is probably going to have to change. Will look it and fix it when I get a chance. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 11:32 Message: Logged In: YES user_id=849994 Originator: NO There is a difference: in the list and int case, the new object is of the base type. In the set case, the new object is of type foo. But the constructor signature argument is a valid one. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-19 11:25 Message: Logged In: YES user_id=80475 Originator: NO Sorry, this is just the way Python works. Given that the __and__ operation has no way of knowing the signature of your subclass contructor, it will produce a new set from your two foo inputs. This design prevades the language (for example list and int have similar behaviors). Recommend closing this as not-a-bug: >>> class foo(list): def __init__(self, iter): print 'foo.__init__' list.__init__(self, iter) >>> x = foo([1,2]) foo.__init__ >>> y = foo([2,3]) foo.__init__ >>> x + y [1, 2, 2, 3] >>> type(_) >>> >>> class foo(int): pass >>> foo(1) + foo(2) 3 >>> type(_) -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 11:11 Message: Logged In: YES user_id=849994 Originator: NO Wasn't that fixed some time ago? @OP: what Python version do you use? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721812&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721890 ] IDLE hangs in popup method completion
Bugs item #1721890, was opened at 2007-05-19 12:23 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=1721890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andy Harrington (andyharrington) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE hangs in popup method completion Initial Comment: import os os. After entering the above code in a new idle editor window, the popup method completion window appears. If I navigate with the down-arrow key, the list starts scrolling fine all the way down to spawnv, which I can select, but if I try to use down-arrow once more and scroll the list (to what would be startfile if I could reach it), idle hangs. Pure pagedown works all the way to in the popup to write, but then it I use up-arrow idle hangs when I try to scroll up beyond startfile to what would be spawnv. I am running Windows XP, service pack 2. On May 5 I installed and am running python-2.5.1.msi. I started idle form idle.bat while in the idlelib directory. I also ran \Python25\Lib\idlelib\idle.pyw from other directories with the same result. I have no such problem with modules os.path or string. I did not think of a module to try which has a list of methods as long as os. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721890&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697215 ] Docstring for site.addpackage() is incorrect
Bugs item #1697215, was opened at 2007-04-09 21:23
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697215&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: cfk (carlfk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Docstring for site.addpackage() is incorrect
Initial Comment:
docstring says "execute sitedir" - but that isn't what gets executed.
suggested:
"""Add a new path to known_paths by combining sitedir and 'name'
or execute lines in name.pth that start with 'import'"""
site.py
def addpackage(sitedir, name, known_paths):
"""Add a new path to known_paths by combining sitedir and 'name' or execute
sitedir if it starts with 'import'"""
fullname = os.path.join(sitedir, name)
f = open(fullname, "rU")
for line in f:
if line.startswith("import"):
exec line
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 18:10
Message:
Logged In: YES
user_id=849994
Originator: NO
Fixed in rev. 55455. (zseil, sorry, I didn't see your patch before
committing it...)
--
Comment By: Ziga Seilnacht (zseil)
Date: 2007-04-15 17:59
Message:
Logged In: YES
user_id=1326842
Originator: NO
Here is a patch. addpackage() is actually responsible
for .pth file processing, so the current docstring was
entirely incorrect.
File Added: addpackage_docstring.diff
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697215&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-1712419 ] Cannot use dict with unicode keys as keyword arguments
Feature Requests item #1712419, was opened at 2007-05-03 22:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1712419&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: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot use dict with unicode keys as keyword arguments
Initial Comment:
Unicode strings cannot be used as keys in dictionaries passed as keyword
argument to a function. For example:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def fn(**kw):
... print repr(kw)
...
>>> fn(**{u'x':1})
Traceback (most recent call last):
File "", line 1, in
TypeError: fn() keywords must be strings
>>>
Unicode strings should be converted to str automatically using the site
specific default encoding or something similar solution.
This bug caused problems when decoding dictionaries from data formats such as
XML or JSON. Usually unicode strings are returned from such modules, such as
simplejson. Manual encoding from unicode to str causes performance loss if this
cannot be done by Python automatically.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-19 18:14
Message:
Logged In: YES
user_id=849994
Originator: NO
Yeah, should be uncontroversial.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-18 23:53
Message:
Logged In: YES
user_id=80475
Originator: NO
Recommend closing this as not-a-bug.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2007-05-04 10:27
Message:
Logged In: YES
user_id=38388
Originator: NO
Python (currently) does not allow non-ASCII identifiers, so it's not
surprising that Unicode parameter names don't work.
It's also a really bad idea to pass data from an AJAX XML or JSON request
directly to a function without doing at least some post-processing of the
data in order to prevent DOS attacks, code injection, etc.
dict((str(key), value) for key, value in kw.iteritems()) is all that's
needed for the above.
BTW, I don't think those few micro-seconds really matter in the face of
XML or JSON decoding, network latency, etc. ;-)
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-05-04 04:10
Message:
Logged In: YES
user_id=849994
Originator: NO
In any case, this is a feature request.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1712419&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583862 ] yield+break stops tracing
Bugs item #1583862, was opened at 2006-10-24 17:55
Message generated for change (Settings changed) made by luks
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&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: 5
Private: No
Submitted By: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield+break stops tracing
Initial Comment:
Here is an example script:
def myiter():
for i in range(10):
yield i
for i in myiter():
break
print "foo"
Now, if I try to trace it:
$ python -m trace --trace --count test.py
--- modulename: threading, funcname: settrace
threading.py(70): _trace_hook = func
--- modulename: test, funcname:
test.py(1): def myiter():
test.py(5): for i in myiter():
--- modulename: test, funcname: myiter
test.py(2): for i in range(10):
test.py(3): yield i
test.py(6): break
c:\python25\lib\ntpath.py:190: RuntimeWarning:
tp_compare didn't return -1 or -2 for exception
if i<=max(p.rfind('/'), p.rfind('\\')):
foo
It stops tracing after the `break` statement. The line
after, `print "foo"`, is not traced nor included in the
coverage output.
I'm not sure RuntimeWarning from ntpath.py is relevant
here, because if I use the trace module in some other
situation it doesn't print it. IMO, it's just a side
effect of some different problem.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-11 18:52
Message:
Logged In: YES
user_id=80475
Originator: NO
Using Py2.5.1, the problem seems to have gone away.
Lukas, can you please verify that it is solved and then close.
===
[EMAIL PROTECTED] ~ $ py25/python -m trace --trace --count test.py
--- modulename: threading, funcname: settrace
threading.py(70): _trace_hook = func
--- modulename: trace, funcname:
(1): --- modulename: trace, funcname:
test.py(1): def myiter():
test.py(6): for i in myiter():
--- modulename: trace, funcname: myiter
test.py(2): for i in range(10):
test.py(3): yield i
test.py(7): break
--- modulename: trace, funcname: myiter
test.py(9): print 'foo'
foo
--
Comment By: Lukas Lalinsky (luks)
Date: 2006-10-24 18:05
Message:
Logged In: YES
user_id=587716
Oh, I forgot. This bug is specific to Python 2.5. It works
fine in 2.4.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721372 ] emphasize iteration volatility for set
Bugs item #1721372, was opened at 2007-05-18 17:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: emphasize iteration volatility for set Initial Comment: For http://docs.python.org/lib/types-set.html>, append the following new sentence to the 2nd paragraph. Iteration over a set returns elements in an indeterminate order, which generally depends on factors outside the scope of the containing program. *Justification:* users should not be expected to understand without being told that iteration order depends on factors outside the scope of the containing program. (Additionally, unlike the documentation for dictionaries, the documentation for sets fails to give a serious warning not to rely on iteration order.) -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 23:29 Message: Logged In: YES user_id=21627 Originator: NO aisaac0, thanks for elaborating. Your remark now convinces me that it was the right thing to reject this change. Ite seems that you suggest that experienced users a) are aware that some objects compare and hash by their id(), and b) that the id() is the address in memory, and c) that the id() will influence the order in which objects are iterated, and d) fail to see that the id() may differ across runs Such users are *not* experienced. There are many more reasons why the id of an object may vary across runs. E.g. Linux 2.6 deliberately randomizes memory management, so that identical processes get their objects allocated at different addresses, to defeat security exploits that rely on deterministic address of things in main memory (there is a system call to disable this randomization) Looking at the entire thread, I agree with Carsten Haese's posting: That even experienced users couldn't diagnose this correctly is because they a) did not receive the source code, and b) were talked into believing that this has to do something with the random module. The library reference is a specification, not a tutorial. -- Comment By: Alan (aisaac0) Date: 2007-05-19 15:09 Message: Logged In: YES user_id=1025672 Originator: YES The previous comment completely misses the point. Again, please see the discussion on c.l.python. Not one of the participants expected sets to be "ordered". What was suprising to them was the order can *change* across sequential executions of an **unchanged** source. This is of course *quite* different than expecting that sets are ordered; I am perplexed that anyone would conflate the two. One cannot credibly argue that anyone who understands that sets are not ordered will not be surprised, since even sophisticated users were as a matter of fact surprised in the c.l.python discussion. (Until it was explained by Peter of course.) A natural conclusion is that the docs should offer better protection against such surprise, since we have concrete evidence that even sophisticated users can be surprised by this. In sum, the previous comment conflates two distinct issues and so fails to address the reasons for the proposed docs patch. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 08:38 Message: Logged In: YES user_id=21627 Originator: NO The documentation already says "Being an unordered collection, sets do not record element position or order of insertion." If users read this and fail to understand the notion of an unordered collection, I see no way of "fixing" this. -- Comment By: Alan (aisaac0) Date: 2007-05-19 04:28 Message: Logged In: YES user_id=1025672 Originator: YES While I do not mind my language being rejected, *something* should be added to warn users. What the previous comment fails to mention is the number of people on c.l.python, some of whom are quite sophisticated users, who failed to discover the source of indeterminacy. Users should not have to "rediscover" this because of a documentation failure. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-19 01:08 Message: Logged In: YES user_id=80475 Originator: NO While the OP knows what he means here, the suggested text does not add clarity, it only makes the subject harder to understand and implies that some mysterious, dark force is in place. Further, the sugge
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 06:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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.5 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Neal Norwitz (nnorwitz) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 19:18 Message: Logged In: YES user_id=33168 Originator: NO Sigh, 4.4.20 and 4.5.20 behave differently. I tested on both, but botched it. :-( It seemed like a good idea to have at least one of the buildbots to use 4.5.20. I upgraded the g4 bot to 4.5.20, since that didn't have any version of bsddb on it. I also installed 4.4.20 on the amd64 buildbot. The x86 gentoo bot probably has 4.1, but it's down right now. Martin's machine has 4.2. Both versions (4.4 and 4.5) require the flag DB_DBT_MALLOC (get() returns an error 22 otherwise). However only 4.4 actually allocates memory. 4.5 doesn't. I checked in revs 55457 (2.5) which should handle this better. Could someone please test and verify I really fixed the problem this time. If it's really fixed, close this bug report. The real change is to conditionally free data if it is a different pointer than we pass in (orig_data). Don't free if they are the same pointer. Tested 4.5 memory leaks with the leaks program and 4.4 with valgrind. File Added: db.c -- Comment By: David Favor (dfavor) Date: 2007-05-19 08:05 Message: Logged In: YES user_id=370230 Originator: YES Just built with latest http://svn.python.org/projects/python/branches/release25-maint pull and problem still remains. -- Comment By: David Favor (dfavor) Date: 2007-05-19 08:04 Message: Logged In: YES user_id=370230 Originator: YES My test was done with latest BerkeleyDB 4.5.20 plain (no patches). -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 03:31 Message: Logged In: YES user_id=849994 Originator: NO I can confirm that the checkin didn't change anything for me. I use bsddb version 4.5.20_p2 from Gentoo. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 00:08 Message: Logged In: YES user_id=21627 Originator: NO (I'm not convinced that Neal's patch could actually fix anything) Can people who were able to reproduce this please report their bdb version also; I was using 4.4. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 00:04 Message: Logged In: YES user_id=21627 Originator: NO dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but I still cannot reproduce the problem... -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 21:38 Message: Logged In: YES user_id=33168 Originator: NO I screwed up the first checkin. The CLEAR_DBT was in the wrong place. The fixes are in: Committed revision 55452. Committed revision 55454. (2.5) -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 20:54 Message: Logged In:
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 06:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&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.5 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Neal Norwitz (nnorwitz) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 19:19 Message: Logged In: YES user_id=33168 Originator: NO File Added: test_get_both.py -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 19:18 Message: Logged In: YES user_id=33168 Originator: NO Sigh, 4.4.20 and 4.5.20 behave differently. I tested on both, but botched it. :-( It seemed like a good idea to have at least one of the buildbots to use 4.5.20. I upgraded the g4 bot to 4.5.20, since that didn't have any version of bsddb on it. I also installed 4.4.20 on the amd64 buildbot. The x86 gentoo bot probably has 4.1, but it's down right now. Martin's machine has 4.2. Both versions (4.4 and 4.5) require the flag DB_DBT_MALLOC (get() returns an error 22 otherwise). However only 4.4 actually allocates memory. 4.5 doesn't. I checked in revs 55457 (2.5) which should handle this better. Could someone please test and verify I really fixed the problem this time. If it's really fixed, close this bug report. The real change is to conditionally free data if it is a different pointer than we pass in (orig_data). Don't free if they are the same pointer. Tested 4.5 memory leaks with the leaks program and 4.4 with valgrind. File Added: db.c -- Comment By: David Favor (dfavor) Date: 2007-05-19 08:05 Message: Logged In: YES user_id=370230 Originator: YES Just built with latest http://svn.python.org/projects/python/branches/release25-maint pull and problem still remains. -- Comment By: David Favor (dfavor) Date: 2007-05-19 08:04 Message: Logged In: YES user_id=370230 Originator: YES My test was done with latest BerkeleyDB 4.5.20 plain (no patches). -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 03:31 Message: Logged In: YES user_id=849994 Originator: NO I can confirm that the checkin didn't change anything for me. I use bsddb version 4.5.20_p2 from Gentoo. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 00:08 Message: Logged In: YES user_id=21627 Originator: NO (I'm not convinced that Neal's patch could actually fix anything) Can people who were able to reproduce this please report their bdb version also; I was using 4.4. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 00:04 Message: Logged In: YES user_id=21627 Originator: NO dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but I still cannot reproduce the problem... -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-18 21:38 Message: Logged In: YES user_id=33168 Originator: NO I screwed up the first checkin. The CLEAR_DBT was in the wrong place. The fixes are
