Neil Schemenauer was running regrtest with -r and got a segfault. He whittled it down to running just -u bsddb test_logging test_bsddb3 This was confirmed on Win2K, Win98, and some version of Linux. He also discovered that the problem went away if test_logging.py's locale.setlocale(locale.LC_ALL, '') was commented out. I've since found that the problem persists if + All the suite.addTest() calls in bsddb/test/test_basics.py are commented out except for suite.addTest(unittest.makeSuite(BTreeMultiDBTestCase)) and + All the entries in test_bsddb3.py's test_modules list are commented out except for 'test_basics', Then running yields this output: test_bsddb3 test01_GetsAndPuts (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test02_DictionaryMethods (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test03_SimpleCursorStuff (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test04_PartialGetAndPut (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test05_GetSize (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test06_Truncate (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test09_MultiDB (bsddb.test.test_basics.BTreeMultiDBTestCase) ... FAIL and that's when the crash happens. I don't have time to dig into this more. Looks like a good one, though!
Tim Peters <tim.one@comcast.net> writes:
I don't have time to dig into this more. Looks like a good one, though!
A quick glance shows it is a heap corruption: #0 0xdbdbdbdb in ?? () #1 0x40977c40 in __bam_c_close (dbc=0x826c058, root_pgno=0, rmroot=0x2) at ../btree/bt_cursor.c:601 #2 0x40997f37 in __db_c_close (dbc=0x826c058) at ../db/db_cam.c:135 #3 0x4054e1e3 in DBCursor_dealloc (self=0x40258d20) at /home/martin/work/py2.3/Modules/_bsddb.c:771 #4 0x080817a7 in _Py_Dealloc (op=0x40258d20) at Objects/object.c:2022 #5 0x08104e32 in frame_dealloc (f=0x826b26c) at Objects/frameobject.c:394 #6 0x080817a7 in _Py_Dealloc (op=0x826b26c) at Objects/object.c:2022 #7 0x080e65d8 in tb_dealloc (tb=0x40a57b34) at Python/traceback.c:41 #8 0x080817a7 in _Py_Dealloc (op=0x40a57b34) at Objects/object.c:2022 #9 0x080e6581 in tb_dealloc (tb=0x40a579f4) at Python/traceback.c:40 #10 0x080817a7 in _Py_Dealloc (op=0x40a579f4) at Objects/object.c:2022 #11 0x08079eaf in insertdict (mp=0x40245854, key=0x40394c28, hash=1492466088, value=0x40a6fc34) at Objects/dictobject.c:379 #12 0x0807a3d7 in PyDict_SetItem (op=0x40245854, key=0x40394c28, value=0x40a6fc34) at Objects/dictobject.c:533 #13 0x0807d710 in PyDict_SetItemString (v=0x40245854, key=0x8119310 "exc_traceback", item=0x40a6fc34) at Objects/dictobject.c:1976 It appears that dbc->dbp->dbenv has been freed already. Interestingly enough, self->mydb->myenvobj->db_env is NULL, which means that env.close() was called for it. The specific test case triggering this problem is test_basic.BasicMultiDBTestCase, apparently as the DBEnv is closed before the cursor. I'm uncertain how this could happen, as a DBEnv carries a db_ref field, counting open databases. Regards, Martin
participants (2)
-
martin＠v.loewis.de -
Tim Peters