Yury Selivanov schrieb am 16.05.2016 um 22:19:
> On 2016-05-16 3:58 AM, Stefan Behnel wrote:
>> Yury Selivanov schrieb am 14.05.2016 um 23:31:
>>> Under some circumstances, in asyncio code that runs in uvloop [1],
>>> cython code segfaults in cython/Cython/Utility/Coroutine.c:
>>>
>>>
>>> static PyObject *
>>> __Pyx_Coroutine_get_qualname(__pyx_CoroutineObject *self)
>>> {
>>> Py_INCREF(self->gi_qualname);
>>> return self->gi_qualname;
>>> }
>>>
>>>
>>> "self->gi_qualname" can be NULL. The correct code is probably:
>>>
>>>
>>> __Pyx_Coroutine_get_qualname(__pyx_CoroutineObject *self)
>>> {
>>> if (self->gi_qualname == NULL) { return __pyx_empty_unicode; }
>>> Py_INCREF(self->gi_qualname);
>>> return self->gi_qualname;
>>> }
>> I wonder why it can be NULL. It's supposed to be set to a string constant
>> at creation time. See GeneratorDefNode in Nodes.py. Is there anything
>> special you are doing with these objects? Could you try to figure out how
>> the ones that have a NULL value here are created?
>
> It's probably because asyncio Future and Task have __del__ methods
> which (may) try to call repr on coroutines. At that point of time,
> maybe the GC breaks the refs.
>
> Would you be able to fix the refs for qualname/name?
It seems that CPython should suffer from the same problem, though. It uses
the same code in the getter.
Also, should we really return an empty string or None? Both feel like
unexpected results, so I can't tell which is better.
And finally, since both name values are guaranteed to be strings (the
setter checks their type), I wonder if we shouldn't just make sure they are
*exactly* Unicode strings by converting any subtypes, and then remove their
Py_CLEAR() from the tp_clear() function. Strings can't participate in
reference cycles, and we could thus report the actual names even during
garbage collection.
Stefan
_______________________________________________
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
