Bug #65091 [Fbk->Opn]: Scanner Bug
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] felipe@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
Thread (5 messages)