php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #34782 token_get_all gives wrong result
Submitted: 2005-10-07 18:06 UTC Modified: 2005-10-21 11:34 UTC
From: linus at mccabe dot nu Assigned: dmitry (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 5CVS-2005-10-08 (snap) OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: linus at mccabe dot nu
New email:
PHP Version: OS:

 

 [2005-10-07 18:06 UTC] linus at mccabe dot nu 
Description:
------------
This is bug 29761, I'd like to see it reopened.
(it might also be 33093, not sure)

Create the two php files in 'reproduce code'.
Point your browser to 'test.php'. First time you should get the expected result, second the actual result.

If you have many apache threads, you might need to refresh a few times until the error occurs.

I've tested and reproduced this on:
* Windows XP: Apache/2.0.52 (Win32) PHP/5.0.5
* Linux: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-15

(yes, error.php is supposed to have a parser error)

thanks for your time

/Linus

Reproduce code:
---------------
error.php:
<?php
     
     print('abc'
     ;
     
?>

test.php:
<?php
     
     header('Content-Type: text/plain');
     
     $first = token_get_all('<?php $a=$b;');
                                   print_r($first);
                                   
                                   require('error.php');
                                   
?>

Expected result:
----------------
Array
(
    [0] => Array
        (
            [0] => 366
            [1] => <?php 
        )

    [1] => Array
        (
            [0] => 309
            [1] => $a
        )

    [2] => =
    [3] => Array
        (
            [0] => 309
            [1] => $b
        )

    [4] => ;
)
<br />
<b>Parse error</b>:  parse error, unexpected ';' in <b>C:\Program Files\Apache Group\Apache2\htdocs\error.php</b> on line <b>4</b><br />


Actual result:
--------------
Array
(
    [0] => <
    [1] => ?
    [2] => Array
        (
            [0] => 307
            [1] => php
        )

    [3] => Array
        (
            [0] => 369
            [1] =>  
        )

    [4] => Array
        (
            [0] => 309
            [1] => $a
        )

    [5] => =
    [6] => Array
        (
            [0] => 309
            [1] => $b
        )

    [7] => ;
)
<br />
<b>Parse error</b>:  parse error, unexpected ';' in <b>C:\Program Files\Apache Group\Apache2\htdocs\error.php</b> on line <b>4</b><br />

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-07 21:56 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip
 [2005-10-08 08:03 UTC] linus at mccabe dot nu 
I tried with php5-win32-latest: Apache/2.0.52 (Win32) PHP/5.1.0RC2-dev

Same behaviour...
 [2005-10-08 08:06 UTC] linus at mccabe dot nu 
I should also add that this is not reproducable with cli version of php (probably because it's always a new process?).

Only with apache module have I seen this behaviour and once it get's into 'error mode' it usually stays that way.

/Linus
 [2005-10-08 13:37 UTC] derick@php.net 
This is probably related to the strange reports about highlight_string doing weird things. If you can, please try to run this:
sudo valgrind /path/to/apachesrc/src/httpd -X
and request the same file twice. If valgrind gives any errors, please put the trace online and provide a link here. With this we see if it is indeed multiple requests causeing this problem.
 [2005-10-08 14:50 UTC] linus at mccabe dot nu 
Here you'll find some valgrind outputs:
http://x.mccabe.nu/public/traces/

I didnt build apache from source, so I used:
valgrind --log-file=./trace1 /usr/sbin/apache -X
I hope its good enough anyway?

The result can be seen in trace1.log, trace2.log and trace3.log.

trace1.log shows was on a request on a small php file that did not include any parsing error or use token_get_all.

trace2.log shows the request of earlier mentioned 'test.php' requested once.

trace3.log shows the request of 'test.php' requested twice and the second time it gave the wrong result.

traceX_full.log is the same request all over again, but using:
valgrind --leak-check=full --log-file=./trace1 /usr/sbin/apache -X

Hope this helps and let me know if there's anything else i can do!

/Linus
 [2005-10-08 18:21 UTC] sniper@php.net 
What configure line did you use? What MPM you use in Apache2?
 [2005-10-08 18:22 UTC] linus at mccabe dot nu 
I did another test and altered test.php to look like:

<?php
     
     header('Content-Type: text/plain');

   register_shutdown_function('term');
     
     $first = token_get_all('<?php $a=$b;');
                                   print_r($first);
                                   
                                   require('error.php');

    function term()
    {
      apache_child_terminate(); 
    }
                                   
?>

After that it gives the correct result every time.
This is of course not an ideal solution, but I thought it might give yet another hint that the failing has something to do with the previous script's error.

Also, I've tried with other errors than parsing errors (like doing division by zero, trigger_error, etc) but nothing else seems to get php into 'error mode'.
 [2005-10-08 18:29 UTC] linus at mccabe dot nu 
I put my phpinfo's in 
http://x.mccabe.nu/public/traces/

one for the linux box and one for the windows box.

On windows I have apache2, binaries supplied by apache foundation.
On Linux I use debian's apache packages, but it's apache 1.3
 [2005-10-21 11:34 UTC] dmitry@php.net 
Ficed in CVS HEAD, PHP_5_1 and PHP_5_0.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Dec 03 17:01:29 2024 UTC