Re: [APC-DEV] Recursive zval patch for review/comments

Gopal V wrote:

> And somehow seems to fix a relatively random, but recurring
> coredump (more on that on monday) with apc-cvs right now on
> centos+apache1+x86.

Traced it down to one of your patches.

#4  0x00ee772a in sma_deallocate (shmaddr=0xb5f90000, offset=18780)
     at /home/gopalv/apc_debug/apc-control/apc_sma.c:259
#5  0x00ee7fe2 in apc_sma_free (p=0xb5f9496c)
     at /home/gopalv/apc_debug/apc-control/apc_sma.c:482
#6  0x00ee3daa in my_destroy_zval (src=0xb5f9496c,
     deallocate=0xee7eed <apc_sma_free>)
     at /home/gopalv/apc_debug/apc-control/apc_compile.c:1603
#7  0x00ee3dd4 in my_destroy_znode (src=0xb5f94968,
     deallocate=0xee7eed <apc_sma_free>)
     at /home/gopalv/apc_debug/apc-control/apc_compile.c:1611
#8  0x00ee3e06 in my_destroy_zend_op (src=0xb5f94950,
     deallocate=0xee7eed <apc_sma_free>)
     at /home/gopalv/apc_debug/apc-control/apc_compile.c:1620
#9  0x00ee43a4 in my_destroy_op_array (src=0xb5f94860,
     deallocate=0xee7eed <apc_sma_free>)
     at /home/gopalv/apc_debug/apc-control/apc_compile.c:1796
#10 0x00ee45a5 in apc_free_op_array (src=0xb5f94860,
     deallocate=0xee7eed <apc_sma_free>)
     at /home/gopalv/apc_debug/apc-control/apc_compile.c:1882

Just because zval->refcount == 0 doesn't mean apc_destroy_zval()
can automatically apc_sma_free() it. This literally corrupts
prv->next with junk from the previous zend_op and crashes happen
relatively randomly.

The real problem is that sma_deallocate() acts rather dumb about
whether it got a valid offset to free or not.

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