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