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
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