Open navytux opened 1 year ago
Kirill Smelkov wrote at 2023-5-24 03:29 -0700:
... Error in test check7ZODBThreads (ZODB.tests.testFileStorage.FileStorageTests) Traceback (most recent call last): ... File "D:\a\ZODB\ZODB\src\ZODB\serialize.py", line 367, in persistent_id raise InvalidObjectReference( ZODB.POSException.InvalidObjectReference:
@d-maurer, do you maybe have an idea about what is going on?
The code at the exception location: if self._jar.get_connection(database_name) is not obj._p_jar: raise InvalidObjectReference( "Attempt to store a reference to an object from " "a separate connection to the same database or " "multidatabase", self._jar, obj, )
The context:
We are serializing an object "obj0"; its connection is self._jar
.
obj
is a subobject of "obj0" for which we want to check
whether it has a persistent id.
We have obj._p_jar is not self._jar
, i.e. obj
and "obj0" have
different connections.
The exception is raised because even though obj
and "obj0" belong
to the same database, they have different connections.
The test has only a single object which could be "obj0": the root object.
obj
is the (new) PersistentMapping
assigned to
root[name]
in ZODBClientThread.get_thread_dict
.
The test thread uses a single connection. Thus, there should be
no reason that "obj0" (i.e. the root object) and obj
(i.e. the new PersistentMapping
) should get different connections.
The test is likely to cause many conflicts.
One hypothesis was that the connection fails to properly clean
up its attributes related to the creation of new objects
(_added
, _creating
, _cache
) in case of conflicts
(and that this might explain the error).
However, I could not detect hints supporting the hypothesis.
Thanks, Dieter. I read your explanations and too looked a bit at that code, and after quick inspection could not see how it could be breaking. But at least I've come with one small improvement so that next time instead of <unprintable InvalidObjectReference object>
we see a bit more informative error message: https://github.com/zopefoundation/ZODB/pull/384.
I'm not sure it is related, but now ubuntu-py38-pure failed with "FAIL code -11" which means that python interpreted got segmentation fault.
it is somehow suspicious that in both cases it was py38 and "pure" kind of tests.
And check_race_loadopen_vs_local_invalidate
"test did not finish within 120 seconds": https://github.com/zopefoundation/ZODB/actions/runs/5091513834/jobs/9151633676 . It seems we need to increase timeout there once again as we already did in ca41ccd1.
(the timeout is again about py38)
CI on current master (8a7e3162) failed on windows-py38-pure with:
@d-maurer, do you maybe have an idea about what is going on?
P.S.
that comes before that is "ok" and is expectedly generated by
test_racetest.py:test_exception
added in 48315c67. Though it might be good to remove that traceback from test output to avoid confusing people when they try to check what is going on in a test failure.