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