[Python-Dev] pdb segfaults in 2.5 trunk?

[Tim Peters]

[Phillip J. Eby]
> ...
> #0  0x401bbaa4 in _int_free () from /lib/libc.so.6
> #1  0x401baa3c in free () from /lib/libc.so.6
> #2  0x080a253e in builtin_raw_input (self=0x0, args=0x4050862c) at
> Python/bltinmodule.c:1759
>
> It appears the problem is an object/mem mismatch: both PyOS_Readline in
> pgenmain.c, and PyOS_StdioReadline use PyObject_MALLOC,

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 PyMem_FREE.
>
> Just to add to the confusion, by the way, the "readline" module dynamically
> sets PyOS_ReadlineFunctionPointer to call_readline, which does its
> allocation with PyMem_MALLOC...
>
> 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).