[Pymilter] pymilter segfaults

[Stuart D. Gathman]

On Thu, 4 Dec 2008, Stuart D. Gathman wrote:

> Is your python code calling the close callback?  It should be called by
> libmilter only.  If your python code calls the close method, then 
> it destroys the milter context - which would lead to segfault when libmilter
> next attempts a callback.  This would be a bug - the callbacks should detect
> if the context has already been destroyed and throw an exception.

It is tricky because it is really designed for only 1 thread at a time
to use a milter context.  

Let me talk to myself for a bit to try and reason it out:

1. The Python close code is just calling getpriv/setpriv.  It doesn't mess with
the libmilter ctx.

2. The libmilter close callback doesn't delete the python milter object.
It destroys the associated PyThreadState and unlinks from libmilter ctx, but
the milter object stays around until references drop to 0.  getpriv/setpriv
from python will continue to work.

3. Should python code attempt to invoke other context methods that require
a libmilter ctx, they call _find_context.  _find_context assumes that
the interpreter is locked *and* that libmilter will not be messing 
with the libmilter ctx since it is waiting for a callback to complete.

4. But suppose that python code invokes a context method when *not* in
a callback?  Or suppose that libmilter gets tired of waiting for
a callback and closes the context asyncronously?  In that case, the libmilter
context might get destroyed while python is trying to use it, causing
a segfault.

Does 4 sound like it might be happening in your milter?  (Does anyone know
if libmilter might call close while another callback hasn't returned?)

-- 
	      Stuart D. Gathman <stuart at bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.