PHP 4.0 Bug #5049: MultiThread -- Access Violation

From: kufan@mail.formosoft.com Operating system: WINNT 4.0 PHP version: 4.0 Beta 4 Patch Level 1 PHP Bug Type: Reproduceable crash Bug description: MultiThread -- Access Violation Environment: NT Server 4.0 SP5, IIS with PHP4 ISAPI, php4isapi.dll, compiled in release_TS or debug_TS. When I access a php page without extension module, every thing is fine. When I access a php page singly with or without extension module, every thing is fine, too. But if I access a php page parallelly with extension module, Access violation always occured. When I debug the php4isapi.dll in debug version, I found that when 2 connection access the php page, they runs in 2 threads. It seems that when thread 1 finish, it release memory thread 2 needed. And when thread 2 access those memory, access violation exception is occured. The most often that access violation occured is in zend_opcode.c. happened at: if (opline->op1.op_type==IS_CONST) { some memory address of op_array seems has been released, and opline = op_array->opcodes is not a valid pointer anymore, that's why exception occured. Below are the 2 call stacks of some situation: 1. HttpExtensionProc php_request_shutdown zend_deactivate shutdown_compiler zend_hash_apply zend_hash_apply_deleter destroy_zend_function destroy_op_array 2. HttpExtensionProc php_execute_script execute compile_filename compile_files v_compile_files zendparse do_begin_function_declaration zend_hash_add_or_update destroy_zend_function destroy_op_array They all happened after thread 1 is terminated. If I modify some code: in compiler_globals_ctor in zend.c modify zend_hash_copy(compiler_globals->function_table, global_function_table, NULL, &tmp_func, sizeof(zend_function)); to zend_hash_copy(compiler_globals->function_table, global_function_table, (copy_ctor_func_t) function_add_ref, &tmp_func, sizeof(zend_function)); and in php_request_shutdown in main.c: // shutdown_memory_manager(CG(unclean_shutdown), 0); no access violation exception happened anymore. I think it's too difficult to trace all code to find out why, and I don't think the modification is correct, because it may cause may memory allocated not be freed.