#38111 [Fbk]: PHP crashes IIS worker process and application pool

2009-02-10 Thread pajoye
 ID:   38111
 Updated by:   paj...@php.net
 Reported By:  svendavidh at hotmail dot com
 Status:   Feedback
 Bug Type: IIS related
 Operating System: Windows Server 2003 Std. Ed. R2
 PHP Version:  5.2.8
 Assigned To:  pajoye
 New Comment:

Yes, a simple phpinfo and then restart IIS is all it need to crash.
(Note: I am using IIS on Vista 64, and have to create a new
Application
Pool and then enable 32-bit application)

As for why we stick with ISAPI:
"1. We have an php extension for handling proprietary protocol and it
has significant overhead on startup. We will try FastCGI, but in the
meantime we keep in in ISAPI mode so that it won't get loaded and
unloaded frequently."

That should not be a problem at all.

"2. FastCGI could be way better, but ISAPI is still a legitimate mode
for PHP. So I am a bit surprise to see you persuade others to use
FastCGI as a way to avoid this bug. Well of course, use Apache or Linux
also "fix" this problem as well."

Nobody maintains it and it is likely to be dropped. It was never stable
and it is very unlikely that we will fix it any time soon. It is also
the recommend way, according to the IIS team (and I work with them on
that).

"BTW, FastCGI is an excellent idea to make PHP more stable. But I am
worry it becomes a way to hide all the thread-safe, memory leak issues
and allow them not being fixed properly."

There is no tread safety issue with fastcgi because this SAPI is not
threaded (like ISAPI or some apache2 sapi). I do not understand your
point with the memory leaks.



Previous Comments:


[2009-02-10 20:55:56] tser at deltacontrols dot com

Just to clarify again.
The crash could be duplicated without any extension loaded, our own
extension is not loaded neither.



[2009-02-10 20:52:28] tser at deltacontrols dot com

Yes, a simple phpinfo and then restart IIS is all it need to crash.
(Note: I am using IIS on Vista 64, and have to create a new Application
Pool and then enable 32-bit application)

As for why we stick with ISAPI:
1. We have an php extension for handling proprietary protocol and it
has significant overhead on startup. We will try FastCGI, but in the
meantime we keep in in ISAPI mode so that it won't get loaded and
unloaded frequently.

2. FastCGI could be way better, but ISAPI is still a legitimate mode
for PHP. So I am a bit surprise to see you persuade others to use
FastCGI as a way to avoid this bug. Well of course, use Apache or Linux
also "fix" this problem as well.


BTW, FastCGI is an excellent idea to make PHP more stable. But I am
worry it becomes a way to hide all the thread-safe, memory leak issues
and allow them not being fixed properly.



[2009-02-06 08:57:32] paj...@php.net

As I can't reproduce it this bug, I wonder why you insist to use the
ISAPI? There is now a fastcgi interface for II5/6/7 and it works _way_
better than the ISAPI.

Does the crash happen too when you use a simple script (say phpinfo())
and using the same procedure?



[2009-02-05 07:24:04] sikle at stx dot net

yep, this is definitely a vista/php/isapi problem. It happens so
frequently that I think a fix would really help!



[2009-02-03 21:19:57] tser at deltacontrols dot com

I have updated the bug with backtrace and have contacted the assigned
developer directly (and convinced him that there is no extension
involved in the crash).

However, since I am not the originator, I cannot change the Status.
Please change the status.
Thanks!



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/38111

-- 
Edit this bug report at http://bugs.php.net/?id=38111&edit=1



#38111 [Fbk]: PHP crashes IIS worker process and application pool

2008-06-24 Thread pajoye
 ID:   38111
 Updated by:   [EMAIL PROTECTED]
 Reported By:  svendavidh at hotmail dot com
 Status:   Feedback
 Bug Type: IIS related
 Operating System: Windows Server 2003 Std. Ed. R2
 PHP Version:  5.1.4
-Assigned To:  
+Assigned To:  pajoye
 New Comment:

To generate a usable backtrace see:

http://bugs.php.net/bugs-generating-backtrace-win32.php 

A script to reproduce it could help as well (even if many scripts may
crash, at least one can help to fix one issue).

I'm waiting some new test systems with IIS6 and 7 and server 2k3, 2k8
and Vista. That will help to reproduce some of the issues you get.




Previous Comments:


[2008-06-25 03:31:25] administrator at newviewlandscape dot com

Same problem running Windows 2003 Server SP2 and PHP 5.2.6. Is there a
stable version of PHP for Windows 2003 Server SP2? I appears this bug
exists though the entire 5.x version.



[2008-06-25 03:15:19] kevin dot webb at f2bc dot net

What's wrong with they backtrace that was provided in the [3 Mar 5:01pm
UTC] oliver at webbworlds dot com post?



[2008-06-19 08:43:48] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2008-06-19 02:08:37] huyhk at yahoo dot com

Same problem for me. 
PHP 5.1.6, Windows 2003 Standard Edition.
I got Event ID 1009 in System Error log so often (10-15 minutes once).
Running Debug Diagnotistic Tool, I got this message

"In w3wp__PID__7784__Date__06_18_2008__Time_10_18_24PM__844__First
chance exception 0XC005.dmp an access violation exception
(0xC005) occured on thread 35 when another module attempted to call
the following unloaded module: php5ts.dll."



[2008-06-11 14:36:42] alexdykes at gmail dot com

I am also seeing this bug running Windows Home Server, this is
basically Server 2k3 SBS edition.  PHP seems to function correctly as
does IIS however when logging into a new RDP session on the server i
have to dismiss this error about 3 times.  Its  manual install of PHP
rather than a binary install.  I'm using PHP 5.2.6 IIS 6.



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/38111

-- 
Edit this bug report at http://bugs.php.net/?id=38111&edit=1