[Python-Dev] assert failure on obmalloc (original) (raw)

Michael Hudson mwh at python.net
Tue Sep 7 17:25:28 CEST 2004


Jeremy Hylton <jhylton at gmail.com> writes:

Failure running the test suite today with -u compiler enabled on Windows XP.

testlogging Assertion failed: bp != NULL, file \code\python\dist\src\Objects\obmalloc.c, line 604 The debugger says the error is here: msvcr71d.dll!assert(const char * expr=0x1e22bcc0, const char * filename=0x1e22bc94, unsigned int lineno=604) Line 306 C python24d.dll!PyObjectMalloc(unsigned int nbytes=100) Line 604 + 0x1b C python24d.dll!PyObjectDebugMalloc(unsigned int nbytes=84) Line 1014 + 0x9 C python24d.dll!PyThreadStateNew(is * interp=0x00951028) Line 136 + 0x7 C python24d.dll!PyGILStateEnsure() Line 430 + 0xc C python24d.dll!tbootstrap(void * bootraw=0x02801d48) Line 431 + 0x5 C python24d.dll!bootstrap(void * call=0x04f0d264) Line 166 + 0x7 C msvcr71d.dll!threadstart(void * ptd=0x026a2320) Line 196 + 0xd C I've been seeing this sort of error on-and-off for at least a year with my Python 2.3 install. It's the usual reason my spambayes popproxy dies. I can't recell seeing it before on Windows or while running the test suite.

Don't debug builds route all PyMem_ calls through PyMalloc? Doesn't pymalloc rely on the GIL being held when it's called? If both of these are true, there's an obvious problem here, because the call to PyMem_NEW in PyThreadState_New certainly isn't called with the GIL held...

This would only be a problem in a debug build, though.

Cheers, mwh

-- Never meddle in the affairs of NT. It is slow to boot and quick to crash. -- Stephen Harris -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html



More information about the Python-Dev mailing list