Christian Heimes added the comment:
Two questions:
* Which versions of Python are vulnerable to the problem? You forgot to
fill in the version list.
* How do we fix the problem? Is it enough to incref the key or must
startkey be protected, too?
--
nosy: +tiran
Guido van Rossum added the comment:
I can reproduce the segfault in 2.2 through 2.4; in 2.5 and 2.6 the
output is this instead:
Test 1, using __eq__(a, b).__nonzero__()
this is never the right answer
*
Test 2, using tuple's tp_richcompare
New Watch 0xf7f8cbac
New Watch 0xf7f8cc0c
Deleting
Guido van Rossum added the comment:
Oops, the same code appeared twice. The new fix fixes both places.
Added file: http://bugs.python.org/file8827/fix1517.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1517
Changes by Guido van Rossum:
Removed file: http://bugs.python.org/file8826/fix1517.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1517
__
___
Python-bugs-list mailing list
Christian Heimes added the comment:
Guido van Rossum wrote:
The key that needs to be INCREF'ed is actually startkey. Patch attached.
What about the second PyObject_RichCompareBool(startkey, key, Py_EQ) a
few lines below inside the for loop?
Christian
__
Guido van Rossum added the comment:
Committed revision 59222 (2.5.2).
Committed revision 59223 (2.6).
Thanks rhamporyncus and jorendorff!!
--
keywords: +patch
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
New submission from Adam Olsen:
(thanks go to my partner in crime, jorendorff, for helping flesh this out.)
lookdict calls PyObject_RichCompareBool without using INCREF/DECREF on
the key passed. It's possible for the comparison to delete the key from
the dict, causing its own argument to be
