[ python-Bugs-1523465 ] threading.Thread Traceback
Bugs item #1523465, was opened at 2006-07-16 17:40 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=1523465&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: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: roee88 (roee88) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Thread Traceback Initial Comment: I'm using the following line in my application: Thread(target = open_new(dest)).start() dest is file path set by user. Got this traceback with python 2.5: File "C:\python25\lib\threading.py", line 460, in __boostrap self.run() File "C:\python25\threading.py, line 440, in run self.__target(*self.__args, **self.kwargs) TypeError: 'bool' object is not callable Worked well with python 2.4 . OS: windows XP 32 bit. Searched for a similar bug report but couldn't find one, sorry if it already been reported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&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-1191699 ] make slices pickable
Feature Requests item #1191699, was opened at 2005-04-28 13:44
Message generated for change (Comment added) made by connelly
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191699&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sebastien de Menten (sdementen)
Assigned to: Raymond Hettinger (rhettinger)
Summary: make slices pickable
Initial Comment:
As suggested by the summary, provide pickability of
slices by default.
Currently one has to use copy_reg module to register
slices as pickables.
--
Comment By: Connelly (connelly)
Date: 2006-07-16 18:55
Message:
Logged In: YES
user_id=1039782
Additional use case: I needed picklable slices when logging method calls to a
database: __setitem__(self, i, x) could not be logged because the database
module attempted to pickle objects such as ('__setitem__', slice(1, 2, 3), []).
For other Python users who have run into this problem: the code needed to
make slices picklable by copy_reg is available at:
http://mail.python.org/pipermail/python-list/2004-November/
248988.html
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-03 00:50
Message:
Logged In: YES
user_id=80475
Okay, sounds reasonable. Will implement when I have time.
--
Comment By: Sebastien de Menten (sdementen)
Date: 2005-04-30 18:02
Message:
Logged In: YES
user_id=820079
Use case for pickable slices.
Let A be a numeric array of size M x N. We want to consider
sub-arrays in this array like A[:4, :] (the first 4 lines of the
array).
If we want to store both the array and the information of
sub-arrays structures, we need to store slices (we can also
store start/end indices of the array ... but this is call a slice
so it would be better to have pickable slices).
In fact, whenever one wants to write generic algorithm
working on "sublist of lists" or "subarrays of arrays" or
"sub-items of collection of items", it is nicer to use slice
objects explicitly and so store them also explicitly.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-30 12:32
Message:
Logged In: YES
user_id=80475
Use cases?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1191699&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1522771 ] Patch #1388073 is not mentioned in NEWS
Bugs item #1522771, was opened at 2006-07-14 16:09 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522771&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Georg Brandl (gbrandl) Summary: Patch #1388073 is not mentioned in NEWS Initial Comment: This patch adds a mention of patch #1388073 (which changed the names of several attributes on unittest.TestCase) to the "Library" subsection of Misc/NEWS for Python 2.5 alpha 1 (since the patch was applied before 2.5a1 was released). -- >Comment By: Collin Winter (collinwinter) Date: 2006-07-16 14:55 Message: Logged In: YES user_id=1344176 Assigned to gbrandl, since he committed the initial patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522771&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1523465 ] threading.Thread Traceback
Bugs item #1523465, was opened at 2006-07-16 13:40 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&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: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: roee88 (roee88) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Thread Traceback Initial Comment: I'm using the following line in my application: Thread(target = open_new(dest)).start() dest is file path set by user. Got this traceback with python 2.5: File "C:\python25\lib\threading.py", line 460, in __boostrap self.run() File "C:\python25\threading.py, line 440, in run self.__target(*self.__args, **self.kwargs) TypeError: 'bool' object is not callable Worked well with python 2.4 . OS: windows XP 32 bit. Searched for a similar bug report but couldn't find one, sorry if it already been reported. -- >Comment By: Tim Peters (tim_one) Date: 2006-07-16 15:01 Message: Logged In: YES user_id=31435 What does `open_new` return? What does print type(open_new(dest)) display in a failing case? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1523465 ] threading.Thread Traceback
Bugs item #1523465, was opened at 2006-07-16 17:40 Message generated for change (Comment added) made by roee88 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&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: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: roee88 (roee88) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Thread Traceback Initial Comment: I'm using the following line in my application: Thread(target = open_new(dest)).start() dest is file path set by user. Got this traceback with python 2.5: File "C:\python25\lib\threading.py", line 460, in __boostrap self.run() File "C:\python25\threading.py, line 440, in run self.__target(*self.__args, **self.kwargs) TypeError: 'bool' object is not callable Worked well with python 2.4 . OS: windows XP 32 bit. Searched for a similar bug report but couldn't find one, sorry if it already been reported. -- >Comment By: roee88 (roee88) Date: 2006-07-16 19:18 Message: Logged In: YES user_id=143 open_new is imported from webbrowser and it returns a boolean (True in that case). This shouldn't conflict with the Thread target. Just as a note, except for the Traceback everything works well. The dest does open. -- Comment By: Tim Peters (tim_one) Date: 2006-07-16 19:01 Message: Logged In: YES user_id=31435 What does `open_new` return? What does print type(open_new(dest)) display in a failing case? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1523465 ] threading.Thread Traceback
Bugs item #1523465, was opened at 2006-07-16 13:40 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&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: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: roee88 (roee88) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Thread Traceback Initial Comment: I'm using the following line in my application: Thread(target = open_new(dest)).start() dest is file path set by user. Got this traceback with python 2.5: File "C:\python25\lib\threading.py", line 460, in __boostrap self.run() File "C:\python25\threading.py, line 440, in run self.__target(*self.__args, **self.kwargs) TypeError: 'bool' object is not callable Worked well with python 2.4 . OS: windows XP 32 bit. Searched for a similar bug report but couldn't find one, sorry if it already been reported. -- >Comment By: Tim Peters (tim_one) Date: 2006-07-16 16:04 Message: Logged In: YES user_id=31435 Why do you imagine it makes sense to pass a boolean as the target? What do you think that should do? As the message said, a bool object is not callable, and, from the docs: """ `target` is the callable object to be invoked by the `run()` method. Defaults to None, meaning nothing is called. """ It doesn't make sense to pass True (or, e.g., an integer, string, list, dict, or anything else that isn't callable). Note that it's not true that Python 2.4 (or any other version of Python) accepted a boolen here either; e.g., $ python Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import threading >>> threading.Thread(target=True).start() >>> Exception in thread Thread-2: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "C:\Python24\lib\threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) TypeError: 'bool' object is not callable -- Comment By: roee88 (roee88) Date: 2006-07-16 15:18 Message: Logged In: YES user_id=143 open_new is imported from webbrowser and it returns a boolean (True in that case). This shouldn't conflict with the Thread target. Just as a note, except for the Traceback everything works well. The dest does open. -- Comment By: Tim Peters (tim_one) Date: 2006-07-16 15:01 Message: Logged In: YES user_id=31435 What does `open_new` return? What does print type(open_new(dest)) display in a failing case? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1523465 ] threading.Thread Traceback
Bugs item #1523465, was opened at 2006-07-16 17:40 Message generated for change (Comment added) made by roee88 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&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: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: roee88 (roee88) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Thread Traceback Initial Comment: I'm using the following line in my application: Thread(target = open_new(dest)).start() dest is file path set by user. Got this traceback with python 2.5: File "C:\python25\lib\threading.py", line 460, in __boostrap self.run() File "C:\python25\threading.py, line 440, in run self.__target(*self.__args, **self.kwargs) TypeError: 'bool' object is not callable Worked well with python 2.4 . OS: windows XP 32 bit. Searched for a similar bug report but couldn't find one, sorry if it already been reported. -- >Comment By: roee88 (roee88) Date: 2006-07-16 20:47 Message: Logged In: YES user_id=143 I'm really sorry, I got confused because of a change between 2.4 and 2.5 in the return value of open_new. Python 2.4 always returns None so there is no exception. After reading the docs I saw I need to use: Thread(target = open_new, args = [dest]).start() Sorry again. Have a nice day :) -- Comment By: Tim Peters (tim_one) Date: 2006-07-16 20:04 Message: Logged In: YES user_id=31435 Why do you imagine it makes sense to pass a boolean as the target? What do you think that should do? As the message said, a bool object is not callable, and, from the docs: """ `target` is the callable object to be invoked by the `run()` method. Defaults to None, meaning nothing is called. """ It doesn't make sense to pass True (or, e.g., an integer, string, list, dict, or anything else that isn't callable). Note that it's not true that Python 2.4 (or any other version of Python) accepted a boolen here either; e.g., $ python Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import threading >>> threading.Thread(target=True).start() >>> Exception in thread Thread-2: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "C:\Python24\lib\threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) TypeError: 'bool' object is not callable -- Comment By: roee88 (roee88) Date: 2006-07-16 19:18 Message: Logged In: YES user_id=143 open_new is imported from webbrowser and it returns a boolean (True in that case). This shouldn't conflict with the Thread target. Just as a note, except for the Traceback everything works well. The dest does open. -- Comment By: Tim Peters (tim_one) Date: 2006-07-16 19:01 Message: Logged In: YES user_id=31435 What does `open_new` return? What does print type(open_new(dest)) display in a failing case? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1523465 ] threading.Thread Traceback
Bugs item #1523465, was opened at 2006-07-16 13:40 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&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: Threads >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: roee88 (roee88) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Thread Traceback Initial Comment: I'm using the following line in my application: Thread(target = open_new(dest)).start() dest is file path set by user. Got this traceback with python 2.5: File "C:\python25\lib\threading.py", line 460, in __boostrap self.run() File "C:\python25\threading.py, line 440, in run self.__target(*self.__args, **self.kwargs) TypeError: 'bool' object is not callable Worked well with python 2.4 . OS: windows XP 32 bit. Searched for a similar bug report but couldn't find one, sorry if it already been reported. -- >Comment By: Tim Peters (tim_one) Date: 2006-07-16 18:20 Message: Logged In: YES user_id=31435 That's OK -- I'm glad you're unstuck now! Closing as Not-a-Bug. -- Comment By: roee88 (roee88) Date: 2006-07-16 16:47 Message: Logged In: YES user_id=143 I'm really sorry, I got confused because of a change between 2.4 and 2.5 in the return value of open_new. Python 2.4 always returns None so there is no exception. After reading the docs I saw I need to use: Thread(target = open_new, args = [dest]).start() Sorry again. Have a nice day :) -- Comment By: Tim Peters (tim_one) Date: 2006-07-16 16:04 Message: Logged In: YES user_id=31435 Why do you imagine it makes sense to pass a boolean as the target? What do you think that should do? As the message said, a bool object is not callable, and, from the docs: """ `target` is the callable object to be invoked by the `run()` method. Defaults to None, meaning nothing is called. """ It doesn't make sense to pass True (or, e.g., an integer, string, list, dict, or anything else that isn't callable). Note that it's not true that Python 2.4 (or any other version of Python) accepted a boolen here either; e.g., $ python Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import threading >>> threading.Thread(target=True).start() >>> Exception in thread Thread-2: Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap self.run() File "C:\Python24\lib\threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) TypeError: 'bool' object is not callable -- Comment By: roee88 (roee88) Date: 2006-07-16 15:18 Message: Logged In: YES user_id=143 open_new is imported from webbrowser and it returns a boolean (True in that case). This shouldn't conflict with the Thread target. Just as a note, except for the Traceback everything works well. The dest does open. -- Comment By: Tim Peters (tim_one) Date: 2006-07-16 15:01 Message: Logged In: YES user_id=31435 What does `open_new` return? What does print type(open_new(dest)) display in a failing case? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523465&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521726 ] isinstance failure in 2.5 Beta 2
Bugs item #1521726, was opened at 2006-07-13 03:56
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance failure in 2.5 Beta 2
Initial Comment:
Linux gosset 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23
UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
./python Lib/test/test_compile.py
File "Lib/test/test_compile.py", line 6, in
class TestSpecifics(unittest.TestCase):
File "Lib/test/test_compile.py", line 399, in test_main
test_support.run_unittest(TestSpecifics)
File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
422, in run_unittest
run_suite(suite, testclass)
File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
407, in run_suiteraise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
File "Lib/test/test_compile.py", line 226, in
test_unary_minus
self.assertTrue(isinstance(eval("%s" % (-sys.maxint
- 1)), int))
./python
Python 2.5b2 (r25b2:50512, Jul 13 2006, 11:33:15)
>>> import sys
>>> print sys.maxint
9223372036854775807
>>> print "%s" % (-sys.maxint - 1)
-9223372036854775808
>>> print isinstance(eval("%s" % (-sys.maxint - 1)), int)
False
>>> print isinstance(eval("%s" % (-sys.maxint)), int)
True
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-16 18:13
Message:
Logged In: YES
user_id=33168
What version of gcc? Is this a duplicate of 1521947.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Bugs item #1521947, was opened at 2006-07-13 10:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: possible bug in mystrtol.c with recent gcc Initial Comment: python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2 fails test_unary_minus in test_compile.py. Some investigating showed that the -ftree-vrp pass of that gcc (implied by -O2) optimizes out the "result == -result" test on line 215 of PyOS_strtol, meaning PyOS_strtol of the most negative long will incorrectly overflow. Python deals with this in this case by constructing a python long object instead of a python int object, so at least in this case the problem is not serious. I have no idea if there is a case where this is a "real" problem. At first I reported this as a gentoo compiler bug, but got the reply that: """ I'm pretty sure it's broken. -LONG_MIN overflows when LONG_MIN < -LONG_MAX, and in standard C as well as "GNU C", behaviour after overflow on signed integer operations is undefined. """ (see https://bugs.gentoo.org/show_bug.cgi?id=140133) So now I'm reporting this here. There seems to be a LONG_MIN constant in limits.h here that could checked against instead, but I have absolutely no idea how standard that is. Or this could be a compiler bug after all, in which case I would appreciate information I Can use to back that up :) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-16 18:13 Message: Logged In: YES user_id=33168 Is this a duplicate of 1521726? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1523610 ] PyArg_ParseTupleAndKeywords potential core dump
Bugs item #1523610, was opened at 2006-07-16 19: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=1523610&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyArg_ParseTupleAndKeywords potential core dump
Initial Comment:
After getting bit by bug 893549, I was noticing that
sometimes I was getting a core dump instead of a
TypeError when PyArg_ParseTupleAndKeywords was skipping
over a type the "skipitem" code does not understand.
There are about 4 problems I will describe (though they
are related, so it's probably not worth filing seperate
bugs).
The problem is that the "levels" variable is passed to
the seterror function uninitialized. If levels does
not happen to contain any 0 elements, then the
iteration code in seterror will go crazy (I will get to
this in a moment).
In the one place where "skipitem" is called, you will
notice it immediately calls seterror() if it returned
an error message. However, "levels" is not set by the
skipitem function, and thus seterror iterates over an
uninitialized value. I suggest setting levels[0] = 0
somewhere in the beginning of the code, since the
expectations of setting the "levels" seems awefully
delicate.
(As a side note, there's no bounds checking on the
levels variable, either. It seems unlikely that
someone will have 32 levels of nested variables, but I
think it points to a general problem with how the
variable is passed around.)
A second fix is to set levels[0] = 0 if setitem fails
before calling seterror().
Now, returning to the "seterror goes crazy" problem I
mentioned earlier, the following code in the seterror
function:
while (levels[i] > 0 && (int)(p-buf) < 220) {
should be:
while (levels[i] > 0 && (int)(p-buf) > 220) {
At least, that's what I'm assuming it is supposed to
be. I think it should be clear why this is bad.
But wait, there's more! The snprintf in seterror call
uses the incorrect size of buf. The following line:
PyOS_snprintf(p, sizeof(buf) - (buf - p),
should be:
PyOS_snprintf(p, sizeof(buf) - (p - buf),
My particular platform (FreeBSD) puts a NUL character
at the end of the buffer. However, since the size of
the buffer is computed incorrectly, this line of code
stomps on the stack (overwritting the levels value in
my case).
Let me know if you have any questions, or want any
sample code.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1523610 ] PyArg_ParseTupleAndKeywords potential core dump
Bugs item #1523610, was opened at 2006-07-16 19:23
Message generated for change (Comment added) made by ehuss
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyArg_ParseTupleAndKeywords potential core dump
Initial Comment:
After getting bit by bug 893549, I was noticing that
sometimes I was getting a core dump instead of a
TypeError when PyArg_ParseTupleAndKeywords was skipping
over a type the "skipitem" code does not understand.
There are about 4 problems I will describe (though they
are related, so it's probably not worth filing seperate
bugs).
The problem is that the "levels" variable is passed to
the seterror function uninitialized. If levels does
not happen to contain any 0 elements, then the
iteration code in seterror will go crazy (I will get to
this in a moment).
In the one place where "skipitem" is called, you will
notice it immediately calls seterror() if it returned
an error message. However, "levels" is not set by the
skipitem function, and thus seterror iterates over an
uninitialized value. I suggest setting levels[0] = 0
somewhere in the beginning of the code, since the
expectations of setting the "levels" seems awefully
delicate.
(As a side note, there's no bounds checking on the
levels variable, either. It seems unlikely that
someone will have 32 levels of nested variables, but I
think it points to a general problem with how the
variable is passed around.)
A second fix is to set levels[0] = 0 if setitem fails
before calling seterror().
Now, returning to the "seterror goes crazy" problem I
mentioned earlier, the following code in the seterror
function:
while (levels[i] > 0 && (int)(p-buf) < 220) {
should be:
while (levels[i] > 0 && (int)(p-buf) > 220) {
At least, that's what I'm assuming it is supposed to
be. I think it should be clear why this is bad.
But wait, there's more! The snprintf in seterror call
uses the incorrect size of buf. The following line:
PyOS_snprintf(p, sizeof(buf) - (buf - p),
should be:
PyOS_snprintf(p, sizeof(buf) - (p - buf),
My particular platform (FreeBSD) puts a NUL character
at the end of the buffer. However, since the size of
the buffer is computed incorrectly, this line of code
stomps on the stack (overwritting the levels value in
my case).
Let me know if you have any questions, or want any
sample code.
--
>Comment By: Eric Huss (ehuss)
Date: 2006-07-16 19:28
Message:
Logged In: YES
user_id=393416
Oops, skip the section about <220 being >220. I've been
staring at it too long. The rest of the issues should be
valid, though.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-957381 ] bdist_rpm fails on redhat9, fc1, fc2
Bugs item #957381, was opened at 2004-05-20 09:05 Message generated for change (Comment added) made by misa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=957381&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Anthony Baxter (anthonybaxter) Summary: bdist_rpm fails on redhat9, fc1, fc2 Initial Comment: distutils bdist_rpm has long been broken for recent versions of RPM (RedHat 9, Fedora Core 1 and 2) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88616 When an RPM contains an executable or shared library, a "-debuginfo" rpm is generated. For instance, the following two packages would be generated: foo-1.0.0-1.i386.rpm foo-debuginfo-1.0.0.1-i386.rpm When distutils is faced with this problem, it prints an error like AssertionError: unexpected number of RPM files found: ['build/bdist.linux-i686/rpm/RPMS/i386/foo-1.0.0-1.i386.rpm', build/bdist.linux-i686/rpm/RPMS/i386/foo-debuginfo-1.0.0-1.i386.rpm'] The bugzilla bug contains a proposed patch, but redhat/fedora developers chose not to accept it for their own build of Python. -- Comment By: Mihai Ibanescu (misa) Date: 2006-07-16 22:34 Message: Logged In: YES user_id=205865 Please see patch 1060577 for a more general approach that should let people build multiple rpms out of a spec file. https://sourceforge.net/tracker/?func=detail&aid=1060577&group_id=5470&atid=305470 -- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 13:18 Message: Logged In: YES user_id=29957 Applied to trunk. Will backport to the 2.3 branch. -- Comment By: Jeff Epler (jepler) Date: 2004-05-21 07:46 Message: Logged In: YES user_id=2772 the "WONTFIX" closure of bugzilla 88616 was already from Fedora days (2004-04-05), so opening a new bug report is unlikely to do much on its own. (in fact, I don't know if it's likely to do more than get closed as a duplicate) Of course, I don't speak for Fedora. If a fix for this new RPM feature is included in Python (for 2.3.5 and 2.4) then I'd guess it's more likely to be added as a patch for a subsequent 2.3.3 or 2.3.4-based Python package, but again I don't speak for the Fedora developers. -- Comment By: Jeremy Sanders (jeremysanders) Date: 2004-05-21 04:46 Message: Logged In: YES user_id=8953 I've opened a bugzilla report for fedora 2 See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123598 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=957381&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1504456 ] xmlcore needs to be documented
Bugs item #1504456, was opened at 2006-06-11 15:50 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlcore needs to be documented Initial Comment: The change from the "xml" package to the "xmlcore" package needs to be documented for Python 2.5. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-17 01:48 Message: Logged In: YES user_id=3066 I've added a brief mention of the xmlcore package in the chapter intro. Each module reference section needs to have something added still. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-20 09:20 Message: Logged In: YES user_id=11375 I've added this to rev. 47044 of the "What's New". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
