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