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