[Python-Dev] latest bsddb3 test problems (original) (raw)

Tim Peters tim.one at comcast.net
Sun Sep 21 23:21:04 EDT 2003

[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.

More information about the Python-Dev mailing list