[spambayes-dev] A new and altogether different bsddb breakage

[Tim Peters]

[Kenny Pitt]
> ...
> Whenever you use direct BDB through the pybsddb/bsddb3/bsddb module
> in a multi-thread/multi-user scenario, you always have to start with
> a call to initialize the DB environment before you can do anything
> else.  You expressed some concern over the breakage on Win98 of the
> tests in test_dbshelve.py.  Unfortunately, the line that always fails
> is that very first and most basic initialization call, the same one
> that we would need to call for any use in SpamBayes.

I don't think there's a problem with that:

C:\Python23>python lib/bsddb/test/test_dbshelve.py -v
test01_basics (__main__.DBShelveTestCase) ... ok
test02_cursors (__main__.DBShelveTestCase) ... ok
test01_basics (__main__.BTreeShelveTestCase) ... ok
test02_cursors (__main__.BTreeShelveTestCase) ... ok
test01_basics (__main__.HashShelveTestCase) ... ok
test02_cursors (__main__.HashShelveTestCase) ... ok
test01_basics (__main__.ThreadBTreeShelveTestCase) ... ok
test02_cursors (__main__.ThreadBTreeShelveTestCase) ... ok
test01_basics (__main__.ThreadHashShelveTestCase) ... ok
test02_cursors (__main__.ThreadHashShelveTestCase) ... ok
test01_basics (__main__.EnvBTreeShelveTestCase) ... ERROR
test02_cursors (__main__.EnvBTreeShelveTestCase) ... ok
test01_basics (__main__.EnvHashShelveTestCase) ... ERROR
test02_cursors (__main__.EnvHashShelveTestCase) ... ok
test01_basics (__main__.EnvThreadBTreeShelveTestCase) ... ERROR
test02_cursors (__main__.EnvThreadBTreeShelveTestCase) ... ok
test01_basics (__main__.EnvThreadHashShelveTestCase) ... ERROR
test02_cursors (__main__.EnvThreadHashShelveTestCase) ... ok

Note that the 4 Env instances of test02_cursors pass.  They're doing the
full-blown open-with-env bit too.  It's the the 4 Env instances of
test01_basics that fail, and all of them die with the same traceback:

Traceback (most recent call last):
  File "lib/bsddb/test/test_dbshelve.py", line 75, in test01_basics
    self.do_open()
  File "lib/bsddb/test/test_dbshelve.py", line 238, in do_open
    self.env.open(homeDir, self.envflags | db.DB_INIT_MPOOL |
                                           db.DB_CREATE)
DBAgainError: (11, 'Resource temporarily unavailable -- unable to join
                    the environment')

This isn't the *first* time test01_basics opens with an env, though.  Line
75 is here:

    def test01_basics(self):
        if verbose:
            print '\n', '-=' * 30
            print "Running %s.test01_basics..." % self.__class__.__name__

        self.populateDB(self.d)
        self.d.sync()
        self.do_close()
        self.do_open() # ********************* LINE 75
        d = self.d

The test setUp() method already does self.do_open() once by the time
test01_basics begins.  So there's something screwed up about how the test
tries to close and reopen the dbshelve (self.d) on this box.  Figuring out
exactly what would require digging into the guts of the stinkin' dbshelve
module, to see how *its* stinkin' close method screws up <wink>.

If I comment out lines 74 and 75 (the back-to-back close()/open() pair), the
4 env instances of test01_basics all pass.  In fact, they all pass if I just
comment out line 74.  They also pass if I replace lines 74 and 75 with:

        self.tearDown()
        self.setUp()
        self.populateDB(self.d)

The only way they don't pass is to do exactly what the test does <wink>.

> ...
> Maybe the best thing is to throw some test code into SpamBayes
> and see if it will even start up on Win98.

Yes.

> I don't have access to a Win98 test system, but if I can code up
> enough support that we can try this out, would you be willing to give
> it a test?

Certainly.

> It will probably be after the holidays before I can get to it, but
> we'll see.

That's fine, there's no rush.  Especially since it will work <wink>.