You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Client side gets a SIGSEGV in _PyObject_LookupAttr, dereferencing an invalid tp pointer read from a posioned v object.
After some reference count debugging, I found that for the rpyc y object (in the client code), accessing __bases__ returns a tuple with refcount=1, and it has a single item whose refcount is 1 as well.
abstract_issubclass() calls abstract_get_bases() to get this refcount=1 tuple, and in the fastpath for single inheritance (tuple size = 1) it loads the single item from the tuple (derived = PyTuple_GET_ITEM(bases, 0)) and then decrements the refcount on the tuple, effectively deallocating the tuple and the derived object (whose only reference was from the tuple).
I tried to mimic the Python magic rpyc does to get the same crash without rpyc, and reached the following snippet (which doesn't exhibit the problem):
In this case, the refcount is decremented from 4 to 3 as abstract_issubclass() gets rid of the tuple (instead of from 1 to 0 as happens in the rpyc case). I don't know how rpyc does it.
Attached is a patch that solves the problem (takes a ref of the tuple item before releasing the ref of the tuple itself).
I'm not sure this change is worth the cost because, well, I don't fully understand the severity of it since I couldn't reproduce it without using rpyc. I assume dynamically-created, unreferenced __bases__ tuples as I have here are not so common.
Anyway, if you do decide it's worth it, I'd be happy to improve the patch (it's quite messy the way this function is structured) and post it to GitHub :)