Edit report at https://bugs.php.net/bug.php?id=65091&edit=1
ID: 65091 User updated by: keithk at powderkeginteractive dot com Reported by: keithk at powderkeginteractive dot com Summary: Scanner Bug -Status: Feedback +Status: Open Type: Bug Package: *General Issues Operating System: Linux PHP Version: 5.5.0 Block user comment: N Private report: N New Comment: Example script: <?php echo 'testing'; ?> Previous Comments: ------------------------------------------------------------------------ [2013-06-24 00:27:39] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with <?php and ends with ?>, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. ------------------------------------------------------------------------ [2013-06-21 21:30:33] keithk at powderkeginteractive dot com Description: ------------ Environment: -Debian Linux Etch, Lenny, Squeeze and Wheezy (standard LAMP stacks) -Oracle Cluster File System (OCFS2) -PHP 5.3, 5.4 and 5.5 (across any of the above systems) PHP 5.3 and above seems to have an issue where the scanner scans past the end of a PHP script, allowing unexpected/junk characters to be tokenized and causing the parser to emit "unexpected ... at end of file" and related failures. This has happened across many different valid PHP scripts, so there isn't any "test script" I can reasonably provide. A common theme among the scripts, however, is that they end with } or some other single-token character. Note that this issue does *not* happen when using PHP 5.2 within the same environment and scripts. I suspect that memory mapping with a look-ahead buffer, as PHP/Zend does, isn't always returning the ideal case of null-padded data. This may be related to the specific use of OCFS2... perhaps one bug revealing another. At any rate, I've investigated the scanner and it does seem to make an assumption that supports the above edge case. The lex_scan function does not check if the buffer pointer is right at the limit, only before or after, allowing the scanner to read past the end of the buffer. Proposed solution: replace all instances of "(YYCURSOR > YYLIMIT)" with "(YYCURSOR >= YYLIMIT)" in Zend/zend_language_scanner.l ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=65091&edit=1
