Repository navigation
Closed
Labels
Description
Description
I'm using the zend_compile_file function for require a file in my extension.
Here is the code:
int requireFile(zval *result, char *path) {
zend_file_handle file_handle;
zend_op_array *new_op_array;
zval dummy, output;
int ret;
ret = php_stream_open_for_zend_ex(path, &file_handle, USE_PATH|STREAM_OPEN_FOR_INCLUDE);
if (ret != SUCCESS) {
return FAILURE;
}
zend_string *filename = zend_string_init(path, strlen(path), 0);
if (!file_handle.opened_path) {
file_handle.opened_path = zend_string_copy(filename);
}
zend_string *opened_path = zend_string_copy(file_handle.opened_path);
ZVAL_NULL(&dummy);
if (zend_hash_add(&EG(included_files), opened_path, &dummy)) {
new_op_array = zend_compile_file(&file_handle, ZEND_REQUIRE);
} else {
new_op_array = NULL;
}
zend_string_release_ex(opened_path, 0);
if (new_op_array) {
ZVAL_UNDEF(&output);
zend_execute(new_op_array, &output);
ZVAL_COPY_VALUE(result, &output);
if (!EG(exception)) {
zval_ptr_dtor(&output);
}
}
zend_string_release(filename);
destroy_op_array(new_op_array);
efree(new_op_array);
zend_destroy_file_handle(&file_handle);
return SUCCESS;
}
Use the function:
zval exist, source;
ZVAL_NULL(&source);
char *basePath, *module, *filename;
size_t basePathLength = 0, moduleLength = 0, filenameLength = 0;
ZEND_PARSE_PARAMETERS_START(3, 3)
Z_PARAM_STRING(basePath, basePathLength)
Z_PARAM_STRING(module, moduleLength)
Z_PARAM_STRING(filename, filenameLength)
ZEND_PARSE_PARAMETERS_END();
char *jsFilePath[] = {basePath, "/resource/", module, "/js/", filename, ".php"};
char jsFile[basePathLength + moduleLength + filenameLength + 18];
globalString(jsFile, jsFilePath, 6);
php_stat(jsFile, strlen(jsFile), FS_EXISTS, &exist);
if (Z_TYPE(exist) == IS_TRUE) {
requireFile(&source, jsFile);
zend_update_static_property(i18nCe, ZEND_STRL("source"), &source);
zval_ptr_dtor(&source);
}
zval_ptr_dtor(&exist);
The globalString function:
void globalString(char result[], char *strs[], int size) {
strcpy(result, strs[0]);
for (int i = 1; i < size; i++) {
strcat(result, strs[i]);
}
}
However, when I try with the valgrind, it show Conditional jump or move depends on uninitialised value(s)
==35079== Memcheck, a memory error detector
==35079== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==35079== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==35079== Command: /root/php-bin/DEBUG/bin/php -S localhost:8000 test/index.php
==35079== Parent PID: 8
==35079==
==35079== Conditional jump or move depends on uninitialised value(s)
==35079== at 0x71B4220: persistent_compile_file (ZendAccelerator.c:2217)
==35079== by 0x72A4E9F: requireFile (require.c:26)
==35079== by 0x72A8CE3: zim_I18n_init (i18n.c:42)
==35079== by 0x76651B: ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER (zend_vm_execute.h:1755)
==35079== by 0x7E8E9F: execute_ex (zend_vm_execute.h:55172)
==35079== by 0x7ED5A7: zend_execute (zend_vm_execute.h:59499)
==35079== by 0x725AAB: zend_execute_scripts (zend.c:1694)
==35079== by 0x83DF3F: php_cli_server_dispatch_router (php_cli_server.c:2168)
==35079== by 0x83E153: php_cli_server_dispatch (php_cli_server.c:2208)
==35079== by 0x83ED67: php_cli_server_recv_event_read_request (php_cli_server.c:2529)
==35079== by 0x83F15B: php_cli_server_do_event_for_each_fd_callback (php_cli_server.c:2615)
==35079== by 0x83A913: php_cli_server_poller_iter_on_active (php_cli_server.c:869)
==35079== Uninitialised value was created by a heap allocation
==35079== at 0x484EFC8: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
==35079== by 0x6E79C7: __zend_malloc (zend_alloc.c:3056)
==35079== by 0x6E649B: _malloc_custom (zend_alloc.c:2418)
==35079== by 0x6E660F: _emalloc (zend_alloc.c:2537)
==35079== by 0x753D07: zend_vm_stack_new_page (zend_execute.c:184)
==35079== by 0x753D6B: zend_vm_stack_init (zend_execute.c:195)
==35079== by 0x709BE7: init_executor (zend_execute_API.c:148)
==35079== by 0x7240EF: zend_activate (zend.c:1212)
==35079== by 0x67510B: php_request_startup (main.c:1725)
==35079== by 0x83DDEB: php_cli_server_request_startup (php_cli_server.c:2130)
==35079== by 0x83E0FF: php_cli_server_dispatch (php_cli_server.c:2199)
==35079== by 0x83ED67: php_cli_server_recv_event_read_request (php_cli_server.c:2529)
==35079==
==35079==
==35079== HEAP SUMMARY:
==35079== in use at exit: 5,032 bytes in 14 blocks
==35079== total heap usage: 15,982 allocs, 15,968 frees, 3,843,232 bytes allocated
==35079==
==35079== LEAK SUMMARY:
==35079== definitely lost: 0 bytes in 0 blocks
==35079== indirectly lost: 0 bytes in 0 blocks
==35079== possibly lost: 0 bytes in 0 blocks
==35079== still reachable: 5,032 bytes in 14 blocks
==35079== suppressed: 0 bytes in 0 blocks
==35079== Reachable blocks (those to which a pointer was found) are not shown.
==35079== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==35079==
==35079== For lists of detected and suppressed errors, rerun with: -s
==35079== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
PHP 8.0.21-dev (cli) (built: Sep 12 2022 14:44:12) ( NTS DEBUG )
Copyright (c) The PHP Group
Zend Engine v4.0.21-dev, Copyright (c) Zend Technologies
with Zend OPcache v8.0.21-dev, Copyright (c), by Zend Technologies
PHP Version
PHP 8.0.21-dev
Operating System
No response
Activity
cmb69 commentedon Sep 14, 2022
Not sure if that's the problem, but that doesn't look right anyway.
/resource//js/.phphas a length of 18 bytes, sojsFile[]has no room for the trailing NUL byte. Consider to usechar jsFile[MAX_PATH];instead.navisoft commentedon Sep 15, 2022
I have adjust to char jsFile[256]; but nothing change.
I think on the first request the new_op_array was cached by opcache. On the second request, it is got from the cache and some "variables" is not processed and cannot be freed.
tstarling commentedon Sep 17, 2022
This is a support request for extension development, it's probably not a bug in PHP. Maybe I would be interested in giving support if the extension were open source. It's not related to #9323, the backtrace is different.
kamil-tekiela commentedon Nov 5, 2026
I believe this was fixed in 8.0.25 by e488f7b. If that's not the case, please open a new GH issue with reproducible steps on master branch.