ctdb status

[tridge at samba.org]

Volker,

 > If we are leaking memory, then I suspect the real problem is a missing
 > talloc_free() somewhere else. I'll have a look this morning and see if
 > I can spot it.

I've committed a fix for this.

What was happening was this:

  - in ctdb_recv_pkt() we were freeing the packet after
    processing. That is the right thing to do in nearly every case, as
    it ensures we don't leak packets. 

  - some of the packet processing routines (in particular
    ctdb_request_dmaster()) needed to keep the packet around for a
    while, so they were stealing the packet into their own hierarchy

  - in one code path, the packet processing routine would steal the
    packet into its own hierarchy, then free that hierarchy. That
    actually makes sense on that code path, but it meant we had a
    double free when ctdb_recv_pkt() also freed the packet

The solution was this:

 - in ctdb_recv_pkt() create a temporary local context, and put the
   packet under that context

 - free this temporary context at the end of ctdb_recv_pkt()

 - if the packet processing function frees, steals or does anything
   else with the packet, then that's now fine, as it just means that
   when we free the temporary context that the packet is no longer a
   child of that context. If the packet processing routine doesn't
   move or free the packet then freeing the temporary context frees
   the packet

This solution applies to all 3 of our packet recv routines (the 3
operation switch routines).

Cheers, Tridge