Bug #72257 [Opn->Fbk]: "get_defined_constants(true)" core dump

Edit report at https://bugs.php.net/bug.php?id=72257&edit=1 ID: 72257 Updated by: bwoebi@php.net Reported by: jccgls001 at 126 dot com Summary: "get_defined_constants(true)" core dump -Status: Open +Status: Feedback Type: Bug Package: Scripting Engine problem Operating System: linux 2.6 PHP Version: 7.0.6 Block user comment: N Private report: N New Comment: The question was rather how it is possible that PHP_VERSION gets a module_number of 1. That module_name[1] == 0x0 is normal and intended as it must be unused. Previous Comments: ------------------------------------------------------------------------ [2016-05-31 06:11:24] jccgls001 at 126 dot com I try my best to debug code with: gdb ./php -n -r "get_defined_constants(true);" and set breakpoint to see why module_names[1]=0x0 ----------------------------------------------------------- (gdb) b zend_builtin_functions.c :2198 Breakpoint 1, zif_get_defined_constants (execute_data=0x7ffff495a0b0, return_value=0x7ffff495a0a0) at /home/users/lvshun/php7/trunk/php/.tmp/build/php-7.0.6/Zend/zend_builtin_functions.c:2198 2198 int i = 1; (gdb) n 2203 module_names[0] = "internal"; <------ Important (gdb) p module_names[0] $1 = 0x134dc1e "internal" in this place, module_names[0] has assigned to "internal", and then: (gdb) n 0x0000000000a6511c in zif_get_defined_constants (execute_data=0x7ffff495a0b0, return_value=0x7ffff495a0a0) (gdb) n 2205 module_names[module->module_number] = (char *)module->name; (gdb) p module->name $2 = 0x134d795 "Core" (gdb) p module->module_number <------ Important, number is 0, but 0 is "internal" $3 = 0 I find "Core" module's number is 0, this means it will rewrite "internal", and then the next module "date": 2204 ZEND_HASH_FOREACH_PTR(&module_registry, module) { (gdb) 0x0000000000a6511c in zif_get_defined_constants (execute_data=0x7ffff495a0b0, return_value=0x7ffff495a0a0) (gdb) 2205 module_names[module->module_number] = (char *)module->name; (gdb) p module->name $5 = 0xde2964 "date" (gdb) p module->module_number $6 = 2 module "data" number is 2! This make me trouble, why "Core" is 0 but "data" is 2. To make this problem clearly, i continue debug code ... ------------------------------------------------ At last, I find the place to assign "Core" module_number. in zend_startup functions, zend engine will load builtin module "Core", these code are: Breakpoint 1, zend_startup_builtin_functions () at /home/users/lvshun/php7/trunk/php/.tmp/build/php-7.0.6/Zend/zend_builtin_functions.c:362 362 zend_builtin_module.module_number = 0; (gdb) l 357 }; 358 /* }}} */ 359 360 int zend_startup_builtin_functions(void) /* {{{ */ 361 { 362 zend_builtin_module.module_number = 0; 363 zend_builtin_module.type = MODULE_PERSISTENT; 364 return (EG(current_module) = zend_register_module_ex(&zend_builtin_module)) == NULL ? FAILURE : SUCCESS; 365 } 366 /* }}} */ as we can see, "Core" module_number assign to 0. Then i debug other module load process and find: (gdb) b zend_API.c:2050 Breakpoint 2 at 0xa3c5ed: file /home/users/lvshun/php7/trunk/php/.tmp/build/php-7.0.6/Zend/zend_API.c, line 2050. (gdb) c Continuing. Breakpoint 2, zend_register_internal_module (module=0x165ac20 <date_module_entry>) at /home/users/lvshun/php7/trunk/php/.tmp/build/php-7.0.6/Zend/zend_API.c:2050 2050 module->module_number = zend_next_free_module(); (gdb) p module->name $1 = 0xde2964 "date" in these codes, other module get number by "zend_next_free_module()", and i step the code: (gdb) step zend_next_free_module () at /home/users/lvshun/php7/trunk/php/.tmp/build/php-7.0.6/Zend/zend_API.c:2643 2643 return zend_hash_num_elements(&module_registry) + 1; (gdb) p module_registry.nNumOfElements $2 = 1 the result is, this will return 2 but not 1. Because module_registry contains "Core". I think the problem is come from here, which "Core" module_number don't use "zend_next_free_module()" but direct assign 0. This will lead other module_name calculate error. --------------------------------------------------------------------- Finally, "Core" module_number = 0, but "data" module_number = 2, so module_names[1]=0x0, this will lead core dump: #1 0x0000000000a652b6 in zif_get_defined_constants (execute_data=0x7ffff76120a0, return_value=0x7ffff7612090) at /home/users/lvshun/php7/trunk/php/.tmp/build/php-7.0.6/Zend/zend_builtin_functions.c:2227 2227 add_assoc_zval(return_value, module_names[module_number], &modules[module_number]); (gdb) p module_names[module_number] $1 = 0x0 (gdb) p module_number $2 = 1 add_assoc_zval expand to add_assoc_zval_ex(__arg, __key, strlen(__key), __value), which strlen(0x0) will make core dump. ----------------------------------------------------------------------- by the way, i add USE_ZEND_ALLOC=0 to see why it can run: Breakpoint 1, zif_get_defined_constants (execute_data=0x7ffff495a0b0, return_value=0x7ffff495a0a0) at /home/users/lvshun/php7/trunk/php/.tmp/build/php-7.0.6/Zend/zend_builtin_functions.c:2227 2227 add_assoc_zval(return_value, module_names[module_number], &modules[module_number]); (gdb) p module_number $2 = 1 (gdb) p module_names[module_number] $3 = 0x302b130b38 "(\v\023+0" <-------- may be USE_ZEND_ALLOC=0 make this value not 0x0 ------------------------------------------------------------------------ [2016-05-30 13:47:13] bwoebi@php.net I have no idea how this can happen. PHP_VERSION is defined at main.c:2107 (in current 7.0 tree) REGISTER_MAIN_STRINGL_CONSTANT() is specifying module_number 0. In case you have enough gdb experience, may you please set a breakpoint there, step a bit forward until allocation of the zend_constant and set a watchpoint on its module number. In case you don't, may you please provide someone of us ssh access able to execute gdb with your php build (a direct email with credentials) so that we can investigate? Else I don't see much we can do here... ------------------------------------------------------------------------ [2016-05-30 13:05:56] jccgls001 at 126 dot com by the way, f 1 locate code : #1 0x0000000000a652b6 in zif_get_defined_constants (execute_data=0x7ffff7612120, return_value=0x7ffff7612090) at /home/users/lvshun_iwm/php7_odp/trunk/php/.tmp/build/php-7.0.6/Zend/zend_builtin_functions.c:2227 2227 add_assoc_zval(return_value, module_names[module_number], &modules[module_number]); (gdb) list 2222 module_number = val->module_number; 2223 } 2224 2225 if (Z_TYPE(modules[module_number]) == IS_UNDEF) { 2226 array_init(&modules[module_number]); 2227 add_assoc_zval(return_value, module_names[module_number], &modules[module_number]); 2228 } 2229 2230 ZVAL_DUP(&const_val, &val->value); 2231 zend_hash_add_new(Z_ARRVAL(modules[module_number]), val->name, &const_val); ------------------------------------------------------------------------ [2016-05-30 13:02:57] jccgls001 at 126 dot com ok and i find module_names[1] is uninitailized value... (gdb) p (char*)module_names[0] <------- this may ‘internal’ ? $1 = 0x134d795 "Core" (gdb) p (char*)module_names[1] <------- problem module, may 'Core' but null $2 = 0x0 (gdb) p (char*)module_names[2] $3 = 0xde2964 "date" (gdb) p (char*)module_number $4 = 0x1 <error: Cannot access memory at address 0x1> (gdb) p (char*)val->name->val $5 = 0x17ecc08 "PHP_VERSION" ------------------------------------------------------------------------ [2016-05-30 12:46:52] bwoebi@php.net Well, module_number 1 should be unused. Can you please give us the faulty constant name with the bad module number? f 1 p (char*)val->name->val ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=72257 -- Edit this bug report at https://bugs.php.net/bug.php?id=72257&edit=1