Verified bug on php 4.0.3/Apache 1.3.12/Redhat Linux 6.2 Intel/DSO, with the exception of memmory growing in 4K increments.(Arch difference from sparc)

I am currently debugging php trying to find the leak. So far it appears that the memmory segment is allocated by the function open_file_for_scanning, and that it is never cleared. I will post more as I find more.

-Jason

Can you please try the latest CVS. A memory leak was fixed.

bug still exists in latest cvs

Well I have been stabbing at this for a really long time. 
I ended up in in zend-scanner.l where I can see lex allocating the 16K block as it should, but I am not sure how to free a block with zends internal engine. Since the sapi module calls open_file_for_scanning, I can see why the block is allocated. I have tried calling zend_destroy_file_handle, since php_execute_script calls it. That did clean the file_handle but not the memmory area. I can also see the that zend_execute_scripts will recycle from already allocated code, but of coure just calling open_file_for_scanning would bypass this and not use a cached instance.  Is there a need to clear the current op_array associated with this? 

I have solved the problem and have a solution. Zend has a function already built for displaying highlighted files, highlight_file, this is the same function called by php's
highlight_file. The sapi module ,however, does not store and reset the lexical state. Therefore, a new state is created with every call to apache_php_module_main.

There are 2 possible solutions. One is too reqrite the sapi module to store the lexical state. The other, the one I am going to send a patch on, is to just call the already written highlight_file function( that way there is one location to modify when this changes. ) I will be writing to php-dev with the fix after I update this

-Jason

I agree with this fix.