Bug #76801 [Opn]: require()ing a file blocks writing or deleting the file

From: Date: Thu, 30 Aug 2018 15:00:03 +0000
Subject: Bug #76801 [Opn]: require()ing a file blocks writing or deleting the file
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-216810@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76801&edit=1 ID: 76801 Updated by: cmb@php.net Reported by: peehaa@php.net Summary: require()ing a file blocks writing or deleting the file Status: Open Type: Bug Package: phpdbg Operating System: Windows PHP Version: 7.2.9 Block user comment: N Private report: N New Comment: It seems that under the CLI SAPI for the included file compile_filename()[1] is called, but not under the phpdbg SAPI. compile_filename() calls zend_destroy_file_hande()[2] after having called zend_compile_file(). I have checked this on Windows only, but I guess the calls are the same on Linux. [1] <https://github.com/php/php-src/blob/php-7.3.0beta2/Zend/zend_language_scanner.l#L643> [2] <https://github.com/php/php-src/blob/php-7.3.0beta2/Zend/zend_language_scanner.l#L672> Previous Comments: ------------------------------------------------------------------------ [2018-08-30 06:03:57] bwoebi@php.net Then I'm seriously confused, as phpdbg_init_compile_file() does exactly the same thing as compile_file() does - what am I missing? ------------------------------------------------------------------------ [2018-08-29 14:41:03] cmb@php.net > So change that patch to just call zend_destroy_file_handle() as > well inside phpdbg_compile_file() (but not the init). That wouldn't fix the issue, though. ------------------------------------------------------------------------ [2018-08-29 11:59:07] bwoebi@php.net No, the caller is the caller calling zend_compile_file(). Compare with the Zend compile_file() https://github.com/php/php-src/blob/php-7.3.0beta2/Zend/zend_language_scanner.l#L621 implementation, which doesn't destroy the handle either Effectively in https://github.com/php/php-src/blob/php-7.3.0beta2/sapi/phpdbg/phpdbg_prompt.c#L627 phpdbg is just mirroring the behavior of compile_filename() https://github.com/php/php-src/blob/php-7.3.0beta2/Zend/zend_language_scanner.l#L672. However, the change in https://github.com/php/php-src/blob/php-7.3.0beta2/sapi/phpdbg/phpdbg_list.c#L291 might be fine, where we create our own file handle thus we must close that properly as well. So change that patch to just call zend_destroy_file_handle() as well inside phpdbg_compile_file() (but not the init). ------------------------------------------------------------------------ [2018-08-28 12:55:07] cmb@php.net > This is a well known issue with windows in general […] Yes. However, the CLI SAPI closes the file handle after inclusion, but the phpdbg SAPI does not, which may not be intended. A comment on phpdbg_compile_file()[1] states that the file handler[sic] is supposed to be freed by original compile_file() or the caller. The caller is phpdbg_init_compile_file()[2] in this case which replaces zend_compile_file[3], so likely phpdbg_init_compile_file() should release the file handle. The attached patch “release-file-handle” would do this. [1] <https://github.com/php/php-src/blob/php-7.3.0beta2/sapi/phpdbg/phpdbg_list.c#L234> [2] <https://github.com/php/php-src/blob/php-7.3.0beta2/sapi/phpdbg/phpdbg_list.c#L296> [3] <https://github.com/php/php-src/blob/php-7.3.0beta2/sapi/phpdbg/phpdbg_list.c#L389> ------------------------------------------------------------------------ [2018-08-28 12:55:04] cmb@php.net The following patch has been added/updated: Patch Name: release-file-handle Revision: 1535460904 URL: https://bugs.php.net/patch-display.php?bug=76801&patch=release-file-handle&revision=1535460904 ------------------------------------------------------------------------ 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=76801 -- Edit this bug report at https://bugs.php.net/bug.php?id=76801&edit=1

« previous php.bugs (#216810) next »