Edit report at https://bugs.php.net/bug.php?id=72257&edit=1
ID: 72257
User updated by: jccgls001 at 126 dot com
Reported by: jccgls001 at 126 dot com
Summary: "get_defined_constants(true)" core dump
-Status: Feedback
+Status: Closed
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:
At last i find the reason why PHP_VERSION module_number = 1...
When we build php source, the shell script will REDEFINE REGISTER_MAIN_STRINGL_CONSTANT and do some
extra job in this macro.
Unfortunately, the replace macro change the module_number param from 0 to 1... I use gdb debug and
find this problem. Now i can continue my work, and i will ask other fellow workers why use 1 but not
0 in this code :(
Thank you for help us find the problem all long, and i also learn much about php7 core~
Previous Comments:
------------------------------------------------------------------------
[2016-05-31 09:15:12] bwoebi@php.net
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.
------------------------------------------------------------------------
[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"
------------------------------------------------------------------------
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