Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with ob handler context and execution in PHP #13965

Open
aswingit opened this issue Apr 15, 2024 · 5 comments
Open

Issue with ob handler context and execution in PHP #13965

aswingit opened this issue Apr 15, 2024 · 5 comments

Comments

@aswingit
Copy link

aswingit commented Apr 15, 2024

Description

I am encountering an issue while working with the "ob_start" function in PHP and the callback parameter.

Description:
When utilizing ob_start("system") to initiate output buffering with the "system" callback in the provided code snippet, I've observed that the zend_get_executed_filename function fails to return the correct file name when the "system" zend function is executed.

This discrepancy occurs particularly when a flush operation happens during php_request_shutdown.

<?php
ob_start("system");
?>

Observations:
Upon debugging, I've noticed the following:

  • Omission of the ob_flush() function call results in the flushing of output handlers during php_request_shutdown.
  • Prior to the invocation of php_output_end_all, the EG(current_execute_data) variable is set to NULL.
  • Consequently, when the "system" function is executed, it operates without the context of the current executed file name, leading to unexpected behavior.

Expected Behavior:
I expect the zend_get_executed_filename function to accurately retrieve the file name, even in scenarios involving flush operations during php_request_shutdown. Is this feasible?

PHP Version

PHP 8.3.3

Operating System

No response

@Girgias
Copy link
Member

Girgias commented Apr 15, 2024

@haszi do you maybe have an idea about this?

@haszi
Copy link
Contributor

haszi commented Apr 15, 2024

No idea as this doesn't seem to be output buffering related. If I understand the above correctly what is being asked here is whether zend_get_executed_filename() can retrieve the current filename during shutdown but as is also mentioned, EG(current_execute_data) is set to NULL. This is the source code and the comment that goes with it:

php-src/main/main.c

Lines 1829 to 1832 in bb6e611

/* EG(current_execute_data) points into nirvana and therefore cannot be safely accessed
* inside zend_executor callback functions.
*/
EG(current_execute_data) = NULL;

@aswingit
Copy link
Author

Thank you. When the shutdown phase occurs and the output handler (in this case, 'system') is executed, it triggers zend_call_function. The issue arises because the current execution context is set to NULL, resulting in the absence of the previous execution context when the system or output handler callback command is executed.

zend_get_executed_filename navigates through the context stack to locate the type of user-defined function in order to retrieve the filename. Without previous context, it's not able to derive filename.

@haszi
Copy link
Contributor

haszi commented Apr 15, 2024

The description of your issue and your question under Expected behavior seem like two different issue to me, but to comment on the first, passing system() to ob_start() will result in a warning as the second argument ob_start() passes to system() is not passed by reference so results in this warning:

PHP Warning: system(): Argument #2 ($result_code) must be passed by reference

I cannot comment on your question other than that the comment in the source code suggests that that is currently not possible.

@aswingit
Copy link
Author

The problem isn't with the 'system' function, but with 'ob_flush'. Let's say I use a custom function from my extension that tries to read zend_get_executed_filename(). It doesn't get the right context when flush occurs during the shutdown phase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants