[Python-Dev] latest bsddb3 test problems
Gregory P. Smith
greg at electricrain.com
Mon Sep 22 03:50:32 EDT 2003
> I'm seeing this fail as well, on Redhat 9. Backing out Greg's changes over
> the weekend doesn't help... the tests still mark as "passed", even though
> there's the fairly horrible error/warnings. I'm guessing something that
> raises an error in a non-main thread doesn't get picked up by regrtest.py
>
> test_bsddb3 is failing on pretty much every box I've tried it on here -
> Solaris and Redhat linux, most running the latest-n-greatest release of
> DB4.1 (we use it pretty heavily in a variety of internal applications).
>
> Solaris 8 (DB 4.1.25. gcc 2.96):
> DBAgainError: (11, 'Resource temporarily unavailable -- mmap: Resource temporarily unavailable')
>
> Solaris 7 (DB 4.1.25, gcc 2.95.2)
> Crashes with a SIGBUS. The version of _bsddb.c from a week ago has a lot of
> errors, but doesn't crash.
That's sounds like inconsistent behaviour. Look at the diffs. All of
the changes since the python 2.3 release to _bsddb.c have been trivial.
The _bsddb.c file version is not the culprit.
> Redhat 10beta/Rawhide (DB 4.1.25)
> DBNoMemoryError: (12, 'Cannot allocate memory -- Lock table is out of available locks')
> alternating with SIGBUS
>
> Redhat 7.1,7.2,7.3 (DB 3.2.9)
> Crashes with a SIGBUS.
>
>
> I'm going to check with Spambayes as an actual application and see whether
> the tests that are failing are at fault, or if we've got something that's
> just busted. Can anyone report the bsddb3 tests as passing on their system?
> Note that they're not run by default.
It is passing on the systems that i've tested it on in the past few days:
(Using BerkeleyDB 4.0, 4.1 and a prerelease of 4.2).
Linux/i686 Gentoo 1.4
Linux/alpha Debian "testing"
I do see the occasional DBDeadLockError which can be ignored. (Yes,
I agree, the test suite needs work to get rid of things like that.
if its not going to consider it an error it should at least catch with
a comment stating why to avoid the confusion)
NOTE: A weakness of the bsddb tests that I have witnessed causing problems:
It often doesn't wipe its temporary directory before the tests (in theory
it should clean up on shutdown, but thats only if all goes well in the
tearDown methods). If a previous run was aborted abnormally and left
a database environment & db around it can cause problems during future
test runs if the testsuite trys to use that environment and db.
> I'm at a loss as to whether to delay the release or not...
>
> Anthony
Do the same tests fail similarly when run on python 2.3? I'd imagine so.
IMHO, I wouldn't hold python 2.3.1 up due to bsddb test suite issues.
-greg
More information about the Python-Dev
mailing list