php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #7199 Memmory leak when calling x-httpd-php-source
Submitted: 2000-10-13 16:58 UTC Modified: 2000-10-14 01:04 UTC
From: jason at inetgurus dot net Assigned:
Status: Closed Package: Apache related
PHP Version: 4.0.3 OS: Solaris 2.7
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jason at inetgurus dot net
New email:
PHP Version: OS:

 

 [2000-10-13 16:58 UTC] jason at inetgurus dot net
There is a memmory leak somewhere when requesting a phps file. Apache in single process mode (httpd -X) will grow exactly 16K each time. I have tested the highlight_file functions and they appear to be fine. This leads me to believe that the leak is apache specific. I have been tracing through trying to find the cause and so far have had no luck

Jason

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-10-13 17:28 UTC] jason at inetgurus dot net
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)
 [2000-10-13 20:41 UTC] jason at inetgurus dot net
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
 [2000-10-13 20:53 UTC] andi@php.net
Can you please try the latest CVS. A memory leak was fixed.
 [2000-10-13 22:20 UTC] jason at inetgurus dot net
bug still exists in latest cvs
 [2000-10-13 23:40 UTC] jason at inetgurus dot net
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? 
 [2000-10-14 00:03 UTC] jason at inetgurus dot net
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
 [2000-10-14 01:04 UTC] rasmus@php.net
I agree with this fix.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Wed Feb 20 16:01:26 2019 UTC