RE: [PHP-QA] Possible Parse Bomb
| From: | James Moore | Date: | Sun, 10 Dec 2000 21:42:12 +0000 |
| Subject: | RE: [PHP-QA] Possible Parse Bomb | ||
| References: | 1 | Groups: | php.qa |
| Request: | Send a blank email to php-qa+get-1793@lists.php.net to get a copy of this message | ||
Joey,
dont be dissappointed if nothing happens. I did 2 million iterations
yesterday and Zak did 1 million and nothing happened for either of us.
Noone can confirm this bug.. what do we do.. run another couple of million
iterations then call it a day and release php 4.0.4 (OR atleast RC5??) what
do others think about this?.
James
-----Original Message-----
From: Joey Smith [mailto:joey@joeysmith.com]
Sent: 10 December 2000 21:33
To: Zak Greant
Cc: PHP Quality Assurance Team Mailing List
Subject: Re: [PHP-QA] Possible Parse Bomb
On Sat, 9 Dec 2000, Zak Greant wrote the following to PHP Quality
Assurance...:
> Hello All,
>
> Zeev recently highlighted possible problems with PHP failing to parse
> requests properly. I would like for us to attempt to recreate this
problem.
> Does anyone have any suggestions on good ways to perform these tests?
<?php
for ($i = 0; $i < 100000; $i++) {
exec("wget http://localhost/a.php");
}
?>
Works pretty well for me. Then just grep * for php keywords....
> Based on Mark's suggestions, I have a few ideas:
>
> Create a nice clean custom log ( + format) to track the results of the
> tests. This will make it easier for us to parse the data.
I think that the above may even make it easier...?
> In the interests of time, we should probably start with the simplest set
of
> tests. Run a simple test many times and see if we get anything that looks
> like a parse bomb. If we don't get any results this way, perhaps move to
a
> more complex text that calls a wide range of functions.
I have this running right now with "a.php" that looks like:
<?php print(2+2); print " is the same as " ; print 4+0; ?>
Once I have completed my 100,000 iterations, I will run it with
something a bit more complex.
> As soon as we can recreate the problem, then move to trying to capture
what
> is actually going on. I don't know if there is any way to easily capture
> the pages output by ab - I am guessing that there is not. If not, and we
can
> recreate the problem, then we should look at writing a script that
requests
> a file, compares the length of the content served to the expected length
and
> captures any odd results.
Assuming I *am* able to generate an error, I will look into some
possible ways to have the php based requesting script check some of
these things. Anyone who has some ideas, feel free to tell me.
> Thoughts, comments?
>
> Zak
>
>
>
--
PHP Quality Assurance Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-qa-unsubscribe@lists.php.net
For additional commands, e-mail: php-qa-help@lists.php.net
To contact the list administrators, e-mail: php-list-admin@lists.php.net