ID: 38111
Comment by: info at cmiwebstudio dot com
Reported By: svendavidh at hotmail dot com
Status: No Feedback
Bug Type: IIS related
Operating System: Windows Server 2003 Std. Ed. R2
PHP Version: 5.2.8
Assigned To: pajoye
New Comment:
PHP 5.2.9
IIS 6
WIN Server 2003 Standard
MySQL 5.1.31
Same problem indicating a problem with php_mbstring.dll . Also getting
"Invalid access to memory location." on PHP pages.
Previous Comments:
------------------------------------------------------------------------
[2009-02-19 04:59:39] sikle at stx dot net
i've resorted to just using apache (via xampp) instead... hrmph.
but atleast now it doesn't crash =)
------------------------------------------------------------------------
[2009-02-18 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, 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".
------------------------------------------------------------------------
[2009-02-10 21:50:51] paj...@php.net
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.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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
