On 11/26/2015 06:06 PM, Luke Deller wrote:
I have come across some dubious code in Objects/weakrefobject.c which looks like a bug to me, but wanted to run it past others.
This was discovered from looking at crash dumps from a multithreaded python app (using Python 2.7.9, but the same weakref code exists in 3.5 and hg tip).
The code that worries me is at the end of the "weakref_richcompare" function:
return PyObject_RichCompare(PyWeakref_GET_OBJECT(self), PyWeakref_GET_OBJECT(other), op);
At this point the code has established that the referents are still alive, and it is trying to compare the referents. However it has not acquired a strong reference to the referents, so I think it is possible for one of them to be deleted half way through this comparison. This can lead to a crash, because PyObject_RichCompare assumes that the PyObject*'s it was passed will remain usable for the duration of the call.
The crashes I have seen involve data corruption consistent with one of these PyObject's being deleted and the memory reused for something else, eg:
00 python27!try_3way_compare+0x15 [objects\object.c @ 712] 01 python27!try_3way_to_rich_compare+0xb [objects\object.c @ 901] 02 python27!do_richcmp+0x2c [objects\object.c @ 935] 03 python27!PyObject_RichCompare+0x99 [objects\object.c @ 982] 04 python27!weakref_richcompare+0x6a [objects\weakrefobject.c @ 212]
(In this example v->ob_type was 0x5f637865 which is ASCII "exc_", not a valid pointer at all)
Other places in weakrefobject.c seem to have a similar weakness, eg in weakref_hash and weakref_repr.
I have not been able to produce a small test case to exhibit this crash, but from this inspection of the code it looks like a bug - am I understanding this correctly?
Luke, go ahead and open an issue on the bug tracker  for this; email threads are too easily lost.