[python-dev-bounces at python.org]
> With current cvs on the release23-maint branch, I get a bunch of
> tracebacks printed to the console without having the test fail.
> I haven't looked at the test at all, so I don't know what any of these
> messages mean. It seems, though, that the test should fail if a
> thread fails with an exception.
I've been told that:
DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to
resolve a deadlock')
isn't an error, it's just something that's going to happen from time to
time. You'll find DeadlockWrap in the traceback then, and the tests
typically do something like
dbutils.DeadlockWrap(d.put, key, self.makeData(key),
max_retries=12)
But the DeadlockWrap implementation suppresses DBLockDeadlockError until
max_retries attempts have been made, so I don't think the tests *expect*
ever to see this get raised. It feels like the moral equivalent of our
ConcurrentUpdates ZEO tests that way.
WRT the rest, we've seen errors like
> AssertionError: None != '1063-1063-1063-1063-1063'
> AssertionError: None != '2000-2000-2000-2000-2000'
> AssertionError: None != '0002-0002-0002-0002-0002'
coming out of Lib/bsddb/test/test_thread.py before, on Windows and on Linux,
but rarely. IIRC, no progress was made in tracking these down, and Barry
and I were dissuaded from pursuing it last time around.
These tests have multiple threads writing to a database, and the exceptions
are due to not finding the data in the database the threads thought they
wrote. In that respect it's also reminiscent of earlier ConcurrentUpdates
ZEO tests. However, these are clearly real test failures, and it's not good
that unittest thinks these tests pass despite that the threads barf.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4