RE: [PHP-QA] Possible Parse Bomb

From: 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

« previous php.qa (#1793) next »