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

Tim Peters tim.peters at gmail.com
Wed Sep 8 05:40:20 CEST 2004

[Michael Hudson]

Don't debug builds route all PyMem calls through PyMalloc?

Indeed they do.

Doesn't pymalloc rely on the GIL being held when it's called?

Indeed it does.

If both of these are true, there's an obvious problem here, because the call to PyMemNEW in PyThreadStateNew certainly isn't called with the GIL held...

Indeed that sucks.

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

So it's Jeremy's fault, just as we suspected all along.

There are lock macros in obmalloc, which currently expand to nothing. They could be changed to "do something" in a debug build, but I'd rather not -- the debug capabilities of obmalloc are more useful the nastier a memory corruption problem is, and few things make problems nastier than throwing threads into the mix.

A cheap trick is to ensure that all code that may be called without the GIL calls the platform malloc()/free() directly. Alas, I haven't been able to reproduce Jeremy's symptom.

More information about the Python-Dev mailing list