Amaury Forgeot d'Arc added the comment:
PyWeakref_GET_OBJECT is also potentially dangerous: since the refcount is not
incremented, it's very possible that the GC collects it.
The only safe operation after PyWeakref_GET_OBJECT is to Py_XINCREF the result.
Should we provide a
Antoine Pitrou added the comment:
The only safe operation after PyWeakref_GET_OBJECT is to Py_XINCREF the
result. Should we provide a PyWeakRef_LockObject()?
There's already a warning in the docs about that. I don't think an additional
function is useful here.
--
Roundup Robot added the comment:
New changeset 0748c22b37e5 by Antoine Pitrou in branch '3.2':
Issue #16602: When a weakref's target was part of a long deallocation chain,
the object could remain reachable through its weakref even though its refcount
had dropped to zero.
Roundup Robot added the comment:
New changeset 7e771f0363e2 by Antoine Pitrou in branch '2.7':
Issue #16602: When a weakref's target was part of a long deallocation chain,
the object could remain reachable through its weakref even though its refcount
had dropped to zero.
Antoine Pitrou added the comment:
Thank you very much for reporting this issue. I believe it is now fixed.
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Eugene Toder added the comment:
Thank you, Antoine.
This change has one effect that's worth highlighting in NEWS at least -- the
PyWeakref_GET_OBJECT() macro now evaluates its argument twice. This can break
existing code where the argument has side-effects, e.g. o =
PyWeakref_GET_OBJECT(p++).
Antoine Pitrou added the comment:
I don't think there's a way to write PyWeakref_GET_OBJECT() in standard
C90 without double evaluation.
Agreed. We generally don't document whether our macros are compatible with side
effects in parameters, and I think we'd like to keep it that way. People
Eugene Toder added the comment:
People should simply avoid doing this kind of thing, as it's knowingly
fragile, and trivial to avoid anyway.
Is this documented in the C API guide, or somewhere else?
In any case, notifying people so they can quickly check their code seems much
nicer than
Antoine Pitrou added the comment:
People should simply avoid doing this kind of thing, as it's
knowingly fragile, and trivial to avoid anyway.
Is this documented in the C API guide, or somewhere else?
I don't think so, but it's common C wisdom that you shouldn't pass
arguments which have
Antoine Pitrou added the comment:
In any case, notifying people so they can quickly check their code
seems much nicer than having them figure this out the hard way.
I see it as a double-edged sword: if we start adding a warning for this
macro, people will expect us to do it for every
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16602
___
___
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16602
___
___
Python-bugs-list mailing list
Antoine Pitrou added the comment:
The easy fix would probably be to return Py_None when the weakref'ed object has
a zero refcount.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16602
___
Eugene Toder added the comment:
Agreed. That's what I've put in my code as a work around.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16602
___
Changes by Daniel Urban urban.dani...@gmail.com:
--
nosy: +daniel.urban
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16602
___
___
New submission from Eugene Toder:
An interaction between weakrefs and trashcan can cause weakref to return the
object it's pointing to after object's refcount is already 0. Given that the
object is usually increfed and decrefed, this leads to double dealloc and
crashing or hanging.
Tested
Christian Heimes added the comment:
Thank you very much for bringing the issue to our attention. I've removed 2.6
and 3.1 because they are in security fix mode and this issue poses no security
threat.
--
nosy: +christian.heimes
stage: - needs patch
versions: +Python 3.4 -Python 2.6,
17 matches
Mail list logo
