Trent, thanks for working on the buildbot. I fixed the first case you mentioned in r61233 wrt removing the directory before closing the file. It would be great if you could submit a patch when you are able to fix the remaining problems.
Cheers, n On Tue, Mar 4, 2008 at 6:58 AM, Trent Nelson <[EMAIL PROTECTED]> wrote: > Spent some time on my buildbot (x86 2k8 trunk) this morning trying to track > down why test_bsddb3 is failing (trunk with db-4.4.20). The first test that > fails is this: > > test01_GetsAndPuts (bsddb.test.test_basics.BasicBTreeWithEnvTestCase) ... > ERROR > > That's slightly misleading though as the test runs fine -- the actual > exception is being thrown in test_basics.BasicTestCase.tearDown() when > os.remove() is called against the first db file (i.e. '__db.001'): > > WindowsError: [Error 5] Access is denied: > 'c:\users\trent~1.nel\appdata\local\temp\2\db_home2808\__db.001 > > This isn't surprising, given that the python_d.exe process still seems to > have __db.001, __db.002 and __db.003 open at the time os.remove() is called. > The aforementioned tearDown() method looks like this: > > def tearDown(self): > self.d.close() > if self.env is not None: > test_support.rmtree(self.homeDir) > self.env.close() > ## Make a new DBEnv to remove the env files from the home dir. > ## (It can't be done while the env is open, nor after it has been > ## closed, so we make a new one to do it.) > #e = db.DBEnv() > #e.remove(self.homeDir) > #os.remove(os.path.join(self.homeDir, self.filename)) > else: > os.remove(self.filename) > > If I switch the order of statements such that self.env.close() is called > before test_suppot.rmtree(self.homeDir), this particular test and a host of > others that were also failing now pass (a runtime abort is no longer raised > by the CRT half way into the tests either). (Note that the order was > switched to that shown above by Neal in r61052 on Feb 24th, which is when > these issues started occurring.) > > That said, there are still a lot more test failures down the track once this > change has been made, either via the access denied WindowsError, or a > DBInvalidArgError, e.g.: > > ERROR: test02_WithSource (bsddb.test.test_recno.SimpleRecnoTestCase) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "S:\src\svn\svn.python.org\projects\python\trunk\lib\bsddb\test\test_recno.py", > line 33, in tearDown > test_support.rmtree(self.homeDir) > File > "S:\src\svn\svn.python.org\projects\python\trunk\lib\test\test_support.py", > line 70, in rmtree > shutil.rmtree(path) > File "S:\src\svn\svn.python.org\projects\python\trunk\lib\shutil.py", line > 184, in rmtree > onerror(os.remove, fullname, sys.exc_info()) > File "S:\src\svn\svn.python.org\projects\python\trunk\lib\shutil.py", line > 182, in rmtree > os.remove(fullname) > WindowsError: [Error 5] Access is denied: > 'c:\\users\\trent~1.nel\\appdata\\local\\temp\\2\\db_home4656\\tmp04_knk' > ====================================================================== > ERROR: test01_1WriterMultiReaders > (bsddb.test.test_thread.BTreeConcurrentDataStore) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "S:\src\svn\svn.python.org\projects\python\trunk\lib\bsddb\test\test_thread.py", > line 62, in setUp > self.env.open(homeDir, self.envflags | db.DB_CREATE) > DBInvalidArgError: (22, 'Invalid argument -- configured environment flags > incompatible with existing environment') > > The DBInvalidArgError exception is only raised after a previous WindowsError > is encountered, so I assume it's a side-effect of the tearDown() method not > cleaning the environment correctly. > > It seems this comment in tearDown() is quite pertinent to our situation: > ## Make a new DBEnv to remove the env files from the home dir. > ## (It can't be done while the env is open, nor after it has been > ## closed, so we make a new one to do it.) > #e = db.DBEnv() > #e.remove(self.homeDir) > #os.remove(os.path.join(self.homeDir, self.filename)) > > Not sure why this is commented out -- quick search of svn history indicates > it's been like that for at least the last year and a half. > > Will have some more time this evening to spend on this, however, work calls > at the moment. > > Regards, > > Trent. > > ________________________________________ > From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Facundo Batista > [EMAIL PROTECTED] > Sent: 26 February 2008 06:22 > To: Thomas Hervé > Cc: python-dev@python.org > Subject: Re: [Python-Dev] Buildbots for trunk are all red > > 2008/2/25, Thomas Hervé <[EMAIL PROTECTED]>: > > > I've worked on that problem during the bug day. I've open a ticket with > > a patch at http://bugs.python.org/issue2168. > > Most of the buildbots are green now!!! > > Thank you all! This community is as awesome as Python itself, ;) > > Three remains in red, though: > > - Alpha Tru64: test_smtplib.py is flaky, and _ssl.c is not compiled > correctly. Neil is hunting this, I think. > > - X86 XP-3: seems to crash after test_bsddb3.py. > > - X86 XP-4: idem. For this two, how can be tried if the bsddb lib in > those windows is correctly installed? > > Thanks again. > > -- > . Facundo > > Blog: http://www.taniquetil.com.ar/plog/ > PyAr: http://www.python.org/ar/ > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/tnelson%40onresolve.com > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
