#16325 [Com]: Memory leak causes DLLHOST to become large
ID: 16325 Comment by: jakub at icewarp dot com Reported By: mail-php dot net at kimihia dot org dot nz Status: Verified Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.3.2RC1 New Comment: Yes it's exactly the same problem as bug #23331. I'm the writer of it. If you need any info I'd like to help. I wrote my own web server so I can test anything... I'd like that to be solved at last. It's been there since the beginning. A little tool generating X hits per second proves it. Cheers J Previous Comments: [2003-08-15 08:48:58] [EMAIL PROTECTED] Isn't this same as bug #23331 is about? (which seems to have a bit more analysis of the problem too) [2003-06-09 03:47:28] [EMAIL PROTECTED] Sorry for the spam. Who are code writers for IIS related stuff? I'm supposed to be the guy who examines all these IIS related bugs, but I've never had to modify the code. [2003-06-09 03:45:08] mail-php dot net at kimihia dot org dot nz I still watch this bug ocassionally, but as I no longer have access to the Windows 2000 Server it is little use. When I left, and when I stepped someone else through it recently when they upgraded, there were using ISAPI for a page that needed to set cookies. Due to the memory problems (which only appear when multiple PHP processes are running) it is not used throughout the entire site. [2003-06-07 06:32:04] nicolai at petri dot cc Same shit still... Why not fix the bug instead of closing this pr constantly ? IIS + PHP + ISAPI is a no-go for all my testcases.. Is anybody actually using this successfully ? [2003-05-29 14:52:26] fer at onplaza dot com Same as others, normally HOSTDLL.EXE grows between 1-2 Mb per request. I've stopped all the rest of services, created a phpinfo.php whith only the named function and a phpinfo.htm; both in the same directory, and if only happens when calling the .php extension page. That's why I think that in this case we are not in front of an IIS problem. Looks like a big leak of memory that in some cases php is unable to handle This is my 6'th year using PHP. Fer The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16325 -- Edit this bug report at http://bugs.php.net/?id=16325&edit=1
#16325 [Com]: Memory leak causes DLLHOST to become large
ID: 16325 Comment by: nicolai at petri dot cc Reported By: mail-php dot net at kimihia dot org dot nz Status: No Feedback Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.3.2RC1 New Comment: Same shit still... Why not fix the bug instead of closing this pr constantly ? IIS + PHP + ISAPI is a no-go for all my testcases.. Is anybody actually using this successfully ? Previous Comments: [2003-05-30 08:43:20] [EMAIL PROTECTED] No feedback from the ORIGINAL bug submitter. [2003-05-29 15:03:27] [EMAIL PROTECTED] reopen, there has been feedback. [2003-05-29 14:52:26] fer at onplaza dot com Same as others, normally HOSTDLL.EXE grows between 1-2 Mb per request. I've stopped all the rest of services, created a phpinfo.php whith only the named function and a phpinfo.htm; both in the same directory, and if only happens when calling the .php extension page. That's why I think that in this case we are not in front of an IIS problem. Looks like a big leak of memory that in some cases php is unable to handle This is my 6'th year using PHP. Fer [2003-04-21 07:25:24] nicolai at petri dot cc This happens also for me with both php 4.3.1 and 4.3.2 RC1. It also happens even if I don´t load any extensions, so the leak seems to be in the core php stuff. I tested with my own pages and phpinfo() pages. Each hit generates 2-3 Mb. of mem. leak. Another (maybe related) observation i did, was that when I run with mssql extension and use pconnect calls.. phpinfo() always shows 0 connections and 0 persistent connections. So maybe php cannot locate it's runtime datastructures and re-allocates them on each hit ? I cannot compile php from sources. But if anyone can point me to a debug build I can try that with memleak detection on. Best regards, Nicolai Petri [2002-11-25 12:01:44] tgl at tgltech dot dk Seems this bug still exists in the 4.2.3 ISAPI. I'm running on Windows 2000 Advanced Server with IIS 5.0. I recently moved to ISAPI instead of CGI as I upgraded from 4.2.1. A week ago I noticed extreme RAM usage. The sites on the server only have < 50 hits / day, so the bug does not require heavy load to appear. I tested it on a page showing phpinfo() and it added 1-2 MB per request. Restarting IIS frees the memory, but that's not really an option. I've tested the latest CVS snapshot and it appears to have the same bug. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16325 -- Edit this bug report at http://bugs.php.net/?id=16325&edit=1
#16325 [Com]: Memory leak causes DLLHOST to become large
ID: 16325 Comment by: fer at onplaza dot com Reported By: mail-php dot net at kimihia dot org dot nz Status: No Feedback Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.1.2 New Comment: Same as others, normally HOSTDLL.EXE grows between 1-2 Mb per request. I've stopped all the rest of services, created a phpinfo.php whith only the named function and a phpinfo.htm; both in the same directory, and if only happens when calling the .php extension page. That's why I think that in this case we are not in front of an IIS problem. Looks like a big leak of memory that in some cases php is unable to handle This is my 6'th year using PHP. Fer Previous Comments: [2003-04-21 07:25:24] nicolai at petri dot cc This happens also for me with both php 4.3.1 and 4.3.2 RC1. It also happens even if I don´t load any extensions, so the leak seems to be in the core php stuff. I tested with my own pages and phpinfo() pages. Each hit generates 2-3 Mb. of mem. leak. Another (maybe related) observation i did, was that when I run with mssql extension and use pconnect calls.. phpinfo() always shows 0 connections and 0 persistent connections. So maybe php cannot locate it's runtime datastructures and re-allocates them on each hit ? I cannot compile php from sources. But if anyone can point me to a debug build I can try that with memleak detection on. Best regards, Nicolai Petri [2002-11-25 12:01:44] tgl at tgltech dot dk Seems this bug still exists in the 4.2.3 ISAPI. I'm running on Windows 2000 Advanced Server with IIS 5.0. I recently moved to ISAPI instead of CGI as I upgraded from 4.2.1. A week ago I noticed extreme RAM usage. The sites on the server only have < 50 hits / day, so the bug does not require heavy load to appear. I tested it on a page showing phpinfo() and it added 1-2 MB per request. Restarting IIS frees the memory, but that's not really an option. I've tested the latest CVS snapshot and it appears to have the same bug. [2002-10-26 01:00:06] 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". [2002-10-10 22:58:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-06-09 08:37:03] abo at irgendware dot com I have the same problem using IIS5.1 with WinXP Pro with PHP4.2.1 as ISAPI module. During 2 seconds 300 MB of RAM where reservated for the service. I had to stop and restart all services and IIS admin to get the memory back. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16325 -- Edit this bug report at http://bugs.php.net/?id=16325&edit=1
#16325 [Com]: Memory leak causes DLLHOST to become large
ID: 16325 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.1.2 New Comment: Seems this bug still exists in the 4.2.3 ISAPI. I'm running on Windows 2000 Advanced Server with IIS 5.0. I recently moved to ISAPI instead of CGI as I upgraded from 4.2.1. A week ago I noticed extreme RAM usage. The sites on the server only have < 50 hits / day, so the bug does not require heavy load to appear. I tested it on a page showing phpinfo() and it added 1-2 MB per request. Restarting IIS frees the memory, but that's not really an option. I've tested the latest CVS snapshot and it appears to have the same bug. Previous Comments: [2002-10-26 01:00:06] [EMAIL PROTECTED] 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". [2002-10-10 22:58:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-06-09 08:37:03] [EMAIL PROTECTED] I have the same problem using IIS5.1 with WinXP Pro with PHP4.2.1 as ISAPI module. During 2 seconds 300 MB of RAM where reservated for the service. I had to stop and restart all services and IIS admin to get the memory back. [2002-03-27 23:06:39] [EMAIL PROTECTED] The setup: IIS5 has an ISAPI application mapping to php4isapi.dll Steps to reproduce: - Start IIS - Generate heavy load (~40+ hits / second) - Watch DLLHOST in the Task Manager. It takes more and more memory (40 - 45MB) - PHP error log begins reporting spurious errors (the page has no errors, but under heavy load it starts complaining about duplicate function definitions) Bug: #13324 - IIS stops serving PHP files but still serves static content DLLHOST disappears from the task list at this point. Other times it may begin taking 100% CPU and need to be terminated by hand. Killing DLLHOST usually causes it to be restarted and requests continue being served. Otherwise you may end up alternating between the two errors on bug #13324. -- Edit this bug report at http://bugs.php.net/?id=16325&edit=1
