Re: [APC-DEV] 3.0.x vs. 3.1.x

Rasmus Lerdorf wrote:

> So at this point I think the strategy should be to take the .16 code and 
> only apply the bug fixes and the removal of the local cache stuff and 
> push out a .18 based on that.

Uhh... that was my initial plan for 0.17 :)

Rasmus  those are the ones I see are new for 3.0.17
g0pz    I think the memleak was a regression?
g0pz    and I don't think the apc_fetch bool one needs merge back
g0pz    is a feature change
g0pz    but I'll merge the sma_allocate() one. the apc_add() one and the
CVE?

I admit it... I was lazy to merge everything, but looks like being
lazy could be a virtue here :)

> It's 7am in Bangalore right now, so Gopal should be coming online in a 
> couple of hours.  He was playing with stuff last night, so let's see if 
> he has found something.

==19278== Invalid read of size 4
==19278==    at 0x4D7FE35: destroy_op_array (zend_opcode.c:228)
....
==19278==  Address 0x7A441F0 is 0 bytes inside a block of size 4 free'd
==19278==    at 0x4804EFA: free (vg_replace_malloc.c:235)
==19278==    by 0x4D6F954: _efree (zend_alloc.c:2274)
==19278==    by 0x5215469: apc_request_shutdown (apc_main.c:615)
==19278==    by 0x520D8B8: zm_deactivate_apc (php_apc.c:309)

Looks like the regression is in the memleak patches by shire. I didn't
pay enough attention when he committed it, but those leaks were ignored
or rather left in-limbo because of past bugs. Other parts of

http://news.php.net/php.pecl.cvs/10041

b0rks up this older "fix" :)

http://cvs.php.net/viewvc.cgi/pecl/apc/apc_main.c?r1=3.98&r2=3.99

The order in which extensions are unloaded and the way they use
memory makes it really hard for APC to zero-copy data without
leaks - memcpy'ing opcodes into local memory is a huge perf-hit,
but the workaround with huge refcounts introduces such leaks.

Maybe I should make it clearer in code.

Cheers,
Gopal
-- 
The difference between insanity and genius is measured by success