Re: removing APC memleak

Gregory Beaver wrote:

Looking at the code with my limited understanding, I was wondering if it is really necessary to duplicate this item for each op_array? It would be easier to simply set it to 1000 each time compilation is requested. My search for any and all decrementing of zend_op_array refcounting only found the instance that occurs immediately after compilation, so in the worst case, refcount would be 999. So is there some other technical reason that apc_copy_op_array_for_execution() uses this code:

    dst->refcount = apc_xmemcpy(src->refcount,
                                      sizeof(src->refcount[0]),
                                      apc_php_malloc);

instead of this code?

    *(dst->refcount) = 1000;

The above change fixes the 4 failing phar tests that leak the 4 byte refcounts when APC is enabled.

A race condition was observed there because dst->refcount is really in shared memory and setting it from multiple processes is prone to corrupt the value. Unless of course, every refcount write used an atomic write/inc macro. Something somewhere sets it to zero and then the free calls stomps over shared memory - but only under high load and once every week or so (followed by all other procs segv'ing on that). And when I say "was" observed, I mean that when we put this leak in, it stopped segv'ing. Since I can't test it exactly, I'd rather have that leak than SEGVs. Cheers, Gopal