PHP :: Bug #7199 :: Memmory leak when calling x-httpd-php-source

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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.

Password:

Status:
Package:
Bug Type:
Summary:
From:	jason at inetgurus dot net
New email:
PHP Version:		OS:

New Comment:

[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.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Sat Apr 20 07:01:29 2024 UTC