[Python-Dev] assert failure on obmalloc

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.
>
> test_logging
> 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
>  	python24_d.dll!PyObject_Malloc(unsigned int nbytes=100)  Line 604 + 0x1b	C
>  	python24_d.dll!_PyObject_DebugMalloc(unsigned int nbytes=84)  Line
> 1014 + 0x9	C
>  	python24_d.dll!PyThreadState_New(_is * interp=0x00951028)  Line 136 + 0x7	C
>  	python24_d.dll!PyGILState_Ensure()  Line 430 + 0xc	C
>  	python24_d.dll!t_bootstrap(void * boot_raw=0x02801d48)  Line 431 + 0x5	C
>  	python24_d.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