[Ctypes-devel] Crash using callback

[Victor S. <vic...@in...>]

Hi,

I wrote a Python binding for libnetfilter_conntrack using ctypes. Ctypes=20
library is really great! It's so easy to write the binding and then to use=
=20
it!

But during tests, I was victim of a crash. After long analys, I understood=
=20
that the problem comes from callback. Here is a little example of the crash:
=2D-- C code ---

typedef int (*callback_t) (int *arg);
callback_t global_callback =3D NULL;
void set_callback(callback_t callback)
{
  global_callback =3D callback;
}

void read_table()
{
    int i;
    static int arg =3D 10;
    if (!global_callback) return;
    for (i=3D0; i<10; i++)
    {
        if (global_callback(&arg) !=3D 0) return;
    }
}

=2D-- Python code ---
lib =3D cdll.LoadLibrary("libbug_callback.so")

def mine(number_ptr):
    return 0

callback_t =3D CFUNCTYPE(c_int, POINTER(c_int))
for subloop in xrange(10000):
    lib.set_callback( callback_t(mine) ) # <~~~ here it is
    lib.read_table()
=2D--

=46ull example is attached to this email (crash_ctypes.tar.bz2).

Or another version of Python code to better understand the bug:
=3D=3D=3D
#=A0using same function and callback type
for subloop in xrange(10000):
    mycallback =3D callback_t(mine)
    lib.set_callback(mycallback)
    del mycallback # <~~~ without this, it doesn't crash
    lib.read_table()
=3D=3D=3D

On my mind, the problem is about object destruction and referrence counting=
=2E=20
It's not really a problem of ctypes, more a problem of object lifetime.

=AB lib.set_callback( callback_t(mine) ) =BB create a temporary object of t=
ype=20
callback_t which is used during the call of lib.set_callback. But after thi=
s=20
call, the object is destroyed. The problem is that the C library stores a=20
pointer to this (destroyed) object. And so it will quickly crash...

Question: would it be possible to change object lifetime, tell that the=20
function keep a referrence of the object, or something like that? Or should=
 I=20
keep a copy of "mycallback =3D callback_t(mine)" somewhere?

Bye,
Victor Stinner
http://www.inl.fr/