SystemError: return without exception set when attempting to load an oid

[cguardia]

We are getting a SystemError where a POSKeyError should be raised, probably due to the exception not being set in the C code. Here is an example traceback (data is an OOBTree):

>>> data.get(u'photo', None)
2018-05-25 18:19:20,336 WARNI [relstorage][MainThread] POSKeyError on oid 57955827: no tid found; history-free adapter
2018-05-25 18:19:20,337 ERROR [ZODB.Connection][MainThread] Couldn't load state for BTrees.OOBTree.OOBTree 0x037455f3
Traceback (most recent call last):
 File "/srv/osfkarl/.buildout/eggs/cp27mu/ZODB-5.2.0-py2.7.egg/ZODB/Connection.py", line 796, in setstate
   p, serial = self._storage.load(oid)
 File "/srv/osfkarl/.buildout/eggs/cp27mu/perfmetrics-2.0-py2.7.egg/perfmetrics/__init__.py", line 127, in call_with_metric
   return f(*args, **kw)
 File "/srv/osfkarl/.buildout/eggs/cp27mu/RelStorage-2.1a2-py2.7-linux-i686.egg/relstorage/storage.py", line 587, in load
   raise POSKeyError(oid)
POSKeyError: 0x037455f3
Traceback (most recent call last):
 File "<console>", line 1, in <module>
SystemError: error return without exception set

This is very similar to #82, but since this is a POSKeyError it might come from a different place in the C code. Or it could be this is just a duplicate. The difference with the other issue is that there is no client disconnect involved.

[jamadden]

Is this something that you can still reproduce?

I'm having difficulty reproducing it with BTrees 4.8, persistent 4.6.4 and ZODB 5.5.1. With the script I added in #161, I can delete either the root of the BTree or some/all of its internal nodes. If the root is deleted, the POSKeyError is percolated to the caller of get; if internal nodes are deleted, the POSKeyError is logged, but get returns cleanly. (Tested both 2.7 and 3.8.)

[cguardia]

Original application is dead, so not the exact same conditions, but a simple attempt at reproducing gave me the same results as yours, so I guess the issue is gone.

[jamadden]

Thanks for responding! Dormant issues like this rarely get all the help you gave.

[jamadden]

I am still worried about #82 but I also can’t reproduce that. There are a lot of places that could go wrong, but by inspection I’m not finding a problem.

To anyone finding this in the future, please file a new issue with a reproducible scenario.