Raising at the c level is typically a critical bug (as it is extra hard for users to debug/patch around) which is why i moved this to 2.0 mile stone

attn @matthew-brett

It works! I built (and got version 2.0.0rc1+79.ga91559b -- I hope that means I applied the pull request right :-) and now in the venv my matplotlib programs are displaying graphs.

Thanks!

Also related https://bugs.python.org/issue18909 (@QuLogic linked to the resulting patch).

My understanding of what is going wrong here (sorry for transcribing some way to picky details):

• we use tkapp.interpaddr to get the memory address of the underlying tk app (so we can get a pointer to it to pass back into tcl to register our custom method onto the interpreter to blit the plot into the GUI)
• under the hood (as of 2013 via python/cpython@bef29fb) this is implemented as

static PyObject *
Tkapp_InterpAddr(PyObject *self, PyObject *args)
{

    if (!PyArg_ParseTuple(args, ":interpaddr"))
        return NULL;

    return PyLong_FromVoidPtr(Tkapp_Interp(self));
}

Prior to this (back to when it was added in 1998) this was implemented as (in python/cpython@83e9f84 )

static PyObject *
Tkapp_InterpAddr(PyObject *self, PyObject *args)
{

    if (!PyArg_ParseTuple(args, ":interpaddr"))
        return NULL;

    return PyInt_FromLong((long)Tkapp_Interp(self));
}

The change is due to a long on win64 being 32bits, but pointers being 64bit (and @cgohlke preemptively saving us from segfaults 👍 )

• previously we were casting this to an Py_ssize_t in the tuple arg parsing step (as that is what the commit message said to do 😉 ) and this works out so long as the integer size and the pointer size line up. In All attempts to plot fail with "OverflowError: Python int too large to convert to C long" #7633 for some reason the pointer coming back is out of range the 32bit range, despite being on a 32bit system. @sandrotosi can you shed any light on what is going on here? Is this a debian cross-compile issue?

• given the current implementation of Tkapp_InterpAddr, switching to PyLong_AsVoidPtr is clearly the correct behavior.

• the PyLong_AsVoidPtr and PyLong_fromVoidPtr come in to python in py1.5.2 so all of our versions are fully supported.

• PyLong_AsVoidPtr will properly up-cast a PyInt to a PyLong so versions of python prior to the above change will also behave correctly.

So, in conclusion, I am convinced that this works in principle and the OP reports that it works in practice so merging.

Based on the issue, the limit may have been assumed to be 31 bits, so if Python/kernel's got some address fuzzing going on (ASLR, maybe), it could produce a 32-bit address that wouldn't fit. I'm not entirely sure about that.