php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #23331 Memory leak in ISAPI
Submitted: 2003-04-24 09:29 UTC Modified: 2003-12-30 01:00 UTC
Votes:16
Avg. Score:4.9 ± 0.2
Reproduced:14 of 15 (93.3%)
Same Version:11 (78.6%)
Same OS:13 (92.9%)
From: jakub at icewarp dot com Assigned:
Status: No Feedback Package: IIS related
PHP Version: 4CVS, 5CVS OS: win32
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: jakub at icewarp dot com
New email:
PHP Version: OS:

 

 [2003-04-24 09:29 UTC] jakub at icewarp dot com 
I have seen a few threads about Memory leaks in the COM object implementation here but from what I see this has never been solved. For instance this little piece of code proves it:

$excel=new COM("Excel.Application");      	  
for ($i=0;$i<50000;$i++) $excel->sheetsinnewworkbook= "1";
die();

It's not always a property that causes the memory leak. It's also the method you call when you pass strings to it. Also when you try to reference a property that does not exist. I'm using my own COM object to test it with and 5000 cycles o calling a simple 3 string parameter function uses up to 30MB of RAM.

Please try to fix it. We have to use a CGI mode where every instance of PHP is freed completely. But we want to use the ISAPI it is not possible to do that now. Thank you
Jakub

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-02 08:44 UTC] jakub at icewarp dot com 
I have found out there is a worse problem. When calling the 
ISAPI DLL function HttpExtensionProc(Extension) to process the PHP session it leaks some memory. If you remove the call it does not leak any memory. I also made sure the WriteClientProc and such procedures in the Extension struct are empty so there could not be any leak from within the web server engine. I also tried to unload the ISAPI dll and this did not free the memory either. When run the 1000x HttpExtensionProc(Extension) to a very easy script like the following:
<?
  echo "Hello";
?>
It leaks about 500kB. I'm not a Linux guy but I suppose if there would be a leak on Linux everybody would already know so I think it might be the ISAPI module problem only. Hopefully.
Thanks Jakub
 [2003-05-03 04:02 UTC] jakub at icewarp dot com 
Some more info I have found.
The DllMain function from the ISAPI dll is incorrectly exported and has the name _DllMain@12 so it cannot be called by the web server. When you call the PROCESS_ATTACH and DETACH DllMain calls it raises and exception. THREAD_ATTACH and DETACH work fine but still the memory leak is there. Each call to the HttpExtensionProc leaks about 1kB of memory. Please try to have a look at it
J
 [2003-05-03 10:22 UTC] jakub at icewarp dot com 
I was wrong about the _DllMain@12 it is called by Windows automatically. However I have found for instance this.
If you load the ISAPI module and free it in a cycle again it does not free the memory.
for ($i=0;$i<1000;$i++)
{
  lh = loadlibrary("...isapi.dll");
  freelibrary(lh);
}
After 200 cycles the process consumes 50MB. I don't think that should happen. What is wrong?
 [2003-08-18 09:31 UTC] sniper@php.net 
You have some extensions loaded in php.ini, right?
Which ones are those? What if you don't load them?
 [2003-08-18 09:42 UTC] jakub at icewarp dot com 
That's what I thought of too so I removed all extensions and the results I posted are without any extensions.
 [2003-10-04 06:17 UTC] jakub at icewarp dot com 
I have been digging more into this issue and I have found this.

1. HttpExtensionProc like this does not leak at all.
DWORD WINAPI HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK lpECB)
{ return 0; }

2. 1. HttpExtensionProc like this does leak.
DWORD WINAPI HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK lpECB)
{
	TSRMLS_FETCH();
	ts_free_thread();
        return 0;
}
It is clear that the ts_free_thread does not free everything. I'm not a C/C++ guru please people help here. This issue has been here since 2 years ago and nobody fixed it yet. Let me know. 
Jakub
 [2003-10-04 08:40 UTC] jakub at icewarp dot com 
I think I tracked down the leak.
In this function:
TSRM_API void *ts_resource_ex(ts_rsrc_id id, THREAD_T *th_id)

There's at the end this:
	TSRM_SAFE_RETURN_RSRC(thread_resources->storage, id, thread_resources->count);

Now if I uncomment this. It does not leak the memory for the 2 calls from my last post. 

The call translates to 
return &thread_resources->storage;

Why should this leak? Please, C++ people help us here.
 [2003-12-14 20:16 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Some fixes have been committed recently which should fix this bug. Please try the snapshot out.
 [2003-12-16 14:31 UTC] msisolak at yahoo dot com 
The recent changes have fixed a big chunk of the leaks, but there are still a couple of memory types that are not getting freed.  I'll have a couple of more patches to close out this bug soon.
 [2003-12-30 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 02:01:29 2024 UTC