|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23331 Memory leak in ISAPI
Submitted: 2003-04-24 09:29 UTC Modified: 2003-12-30 01:00 UTC
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
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
15 - 10 = ?
Subscribe to this entry?

 [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";

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


Add a Patch

Pull Requests

Add a Pull Request


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
 [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");
After 200 cycles the process consumes 50MB. I don't think that should happen. What is wrong?
 [2003-08-18 09:31 UTC]
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.
{ return 0; }

2. 1. HttpExtensionProc like this does leak.
        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. 
 [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]
Please try using this CVS snapshot:
For Windows:

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: Tue Jul 23 09:01:29 2024 UTC