test_bsddb3.py fails quickly today under a debug build, with a thread state
error, on Win2K, every time. Linux?
I assume this is a bad interaction between Mark Hammond's new
auto-thread-state code and _bsddb.c's custom thread-manipulation macros:
C:\Code\python\PCbuild>python_d ../lib/test/test_bsddb3.py
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)
bsddb.db.version(): (4, 1, 25)
bsddb.db.__version__: 4.1.5
bsddb.db.cvsid: $Id: _bsddb.c,v 1.11 2003/03/31 19:51:29 bwarsaw Exp $
python version: 2.3a2+ (#39, Apr 22 2003, 10:48:23) [MSC v.1200 32
bit (I
ntel)]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Fatal Python error: Invalid thread state for this thread
C:\Code\python\PCbuild>
It's dying in _db_associateCallback, here:
static int
_db_associateCallback(DB* db, const DBT* priKey, const DBT* priData,
DBT* secKey)
{
int retval = DB_DONOTINDEX;
DBObject* secondaryDB = (DBObject*)db->app_private;
PyObject* callback = secondaryDB->associateCallback;
int type = secondaryDB->primaryDBType;
PyObject* key;
PyObject* data;
PyObject* args;
PyObject* result;
if (callback != NULL) {
MYDB_BEGIN_BLOCK_THREADS; ************ HERE *************
The macro is defined like so:
#define MYDB_BEGIN_BLOCK_THREADS { \
PyThreadState* prevState; \
PyThreadState* newState; \
PyEval_AcquireLock(); \
newState = PyThreadState_New(_db_interpreterState); \
prevState = PyThreadState_Swap(newState);
PyThreadState_Swap is complaining here:
#if defined(Py_DEBUG)
if (new) {
PyThreadState *check = PyGILState_GetThisThreadState();
if (check && check != new)
Py_FatalError("Invalid thread state for this thread");
}
#endif
This is a new check, I believe it's an intentional check, and I doubt
_bsddb.c *should* pass it as-is.
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