[Python-Dev] pdb segfaults in 2.5 trunk? (original) (raw)

Tim Peters tim.peters at gmail.com
Mon Apr 10 22:57:15 CEST 2006

[Phillip J. Eby]

... #0 0x401bbaa4 in intfree () from /lib/libc.so.6 #1 0x401baa3c in free () from /lib/libc.so.6 #2 0x080a253e in builtinrawinput (self=0x0, args=0x4050862c) at Python/bltinmodule.c:1759

It appears the problem is an object/mem mismatch: both PyOSReadline in pgenmain.c, and PyOSStdioReadline use PyObjectMALLOC,

That wasn't true yesterday, but Neal changed it while you slept ;-). He changed it to worm around a different case of object/mem mismatch.

but bltinmodule.c is freeing the pointer with PyMemFREE.

Just to add to the confusion, by the way, the "readline" module dynamically sets PyOSReadlineFunctionPointer to callreadline, which does its allocation with PyMemMALLOC... So does anybody know what the protocol should be for readline functions? What about readline implementations that are "in the field", so to speak? (e.g. modules that use the readline hook to implement that functionality using something other than GNU readline).

It's documented (after a fashion) at the declaration of PyOS_ReadlineFunctionPointer. Yesterday that read:

""" /* By initializing this function pointer, systems embedding Python can override the readline function.

Note: Python expects in return a buffer allocated with PyMem_Malloc. */

char *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, char *); """

Overnight, "PyMem_Malloc" there changed to "PyObject_Malloc". It didn't matter in practice before (2.5) because all PyXYZ_ABC ways to spell "free the memory" resolved to PyObject_Free. Now that PyMem_ and PyObject_ call different things, mismatches are deadly. Since the only docs we had said PyMem_Malloc must be used for the readline function, best to stick with that. It's messy, though (there are a lot of functions that think they're in charge of freeing the memory, and the memory can originally come from a lot of places).

More information about the Python-Dev mailing list