You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While attempting to reproduce an issue in our own PHP extension using valgrind, I've stumbled upon a bunch of complaints regarding php_var_unserialize_internal() as called via apc_cache_fetch() etc. The test involved ~40 requests started at about the same time and I can't reproduce this issue:
Sample trace:
==288== Conditional jump or move depends on uninitialised value(s)
==288== at 0x5AA3E4: php_var_unserialize_internal (var_unserializer.c:1066)
==288== by 0x5AABA4: process_nested_array_data (var_unserializer.c:482)
==288== by 0x5AABA4: php_var_unserialize_internal (var_unserializer.c:1742)
==288== by 0x5AAC1A: process_nested_array_data (var_unserializer.c:511)
==288== by 0x5AAC1A: php_var_unserialize_internal (var_unserializer.c:1742)
==288== by 0x5AC74A: php_var_unserialize (var_unserializer.c:853)
==288== by 0x56A6D58: php_apc_unserializer (apc_cache.c:260)
==288== by 0x56ACFD2: apc_unpersist_serialized (apc_persist.c:516)
==288== by 0x56ACFD2: apc_unpersist (apc_persist.c:643)
==288== by 0x56A7A19: apc_cache_fetch (apc_cache.c:832)
==288== by 0x56A5217: zif_apcu_fetch (php_apc.c:640)
==288== by 0x6BBCC5: ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER (zend_vm_execute.h:1312)
==288== by 0x6BBCC5: execute_ex (zend_vm_execute.h:56020)
==288== by 0x6C0C5D: zend_execute (zend_vm_execute.h:60384)
==288== by 0x642EBD: zend_execute_scripts (zend.c:1780)
==288== by 0x5CC2FC: php_execute_script (main.c:2553)
Update: I can randomly reproduce this or similar issues, almost all with apc in the call stack. There's a new variation with php_apc_serializer() that ocurred a few times:
==1616== Use of uninitialised value of size 8
==1616== at 0x6CB8FC: lshift (zend_strtod.c:1041)
==1616== by 0x6CFBEB: zend_dtoa (zend_strtod.c:4207)
==1616== by 0x6D0A76: zend_gcvt (zend_strtod.c:4520)
==1616== by 0x5949F4: php_var_serialize_intern.part.0 (var.c:1039)
==1616== by 0x5974D5: php_var_serialize_intern (var.c:997)
==1616== by 0x5974D5: php_var_serialize_nested_data (var.c:971)
==1616== by 0x594C41: php_var_serialize_intern.part.0 (var.c:1254)
==1616== by 0x597528: php_var_serialize_intern (var.c:997)
==1616== by 0x597528: php_var_serialize_nested_data (var.c:965)
==1616== by 0x594C41: php_var_serialize_intern.part.0 (var.c:1254)
==1616== by 0x59A520: php_var_serialize_intern (var.c:997)
==1616== by 0x59A520: php_var_serialize (var.c:1269)
==1616== by 0x56A6C69: php_apc_serializer (apc_cache.c:229)
==1616== by 0x56AC1C0: apc_persist_calc_serialize (apc_persist.c:180)
==1616== by 0x56AC1C0: apc_persist_calc_zval (apc_persist.c:200)
==1616== by 0x56ACC70: apc_persist_calc (apc_persist.c:229)
==1616== by 0x56ACC70: apc_persist (apc_persist.c:453)
While attempting to reproduce an issue in our own PHP extension using valgrind, I've stumbled upon a bunch of complaints regarding php_var_unserialize_internal() as called via apc_cache_fetch() etc. The test involved ~40 requests started at about the same time and I can't reproduce this issue:
Sample trace:
apc-valgrind.txt
The text was updated successfully, but these errors were encountered: