I can't reproduce it, can you try using the RC4 or cvs snapshot please?

>I can't reproduce it

You can't repoduce it unless you use FASTCGI mode.
Try for example with IIS/FastCGI or any other FastCGI runner.

>can you try using the RC4 

I thought RC4 is not available. www.php.net still shows RC3.
Where can I find RC4?

I meant RC3 :)

I do use fastcgi, with IIS7. The VC9-x86 build.

Can you send me a zip (or a link to it) with the php.ini causing the crash? Maybe it is not the comment but some hidden chars.

php.ini, just one line:

#extension_dir=./

screenshot: http://www.image123.net/9bclxbny3f1fpic.html

Looks like VC6, I'd to try it again.

Thanks for the feedback

btw, for what I can read in the screenshot, you are executing the php.ini :) Is it really what you want?

Hi.

Using Windows Server 2008 Enterprise with IIS7 (V7.0.6000.16386) with PHP V5.3.0RC4-dev 
(Build date Jun 16 2009 08:56:09, Compiler MSVC9 (Visual C++ 2008) x86) with Server API CGI/FastCGI (Is that enough detail?).

Using 

#extension_dir = C:/PHP5/ext
and
extension_dir = C:/PHP5/ext

(restarting IIS in between each change).

No problems.

Sure extensions aren't available (as seen in phpinfo()). With the # I have 34 
extensions loaded (count(get_loaded_extensions()) vs 58 without the # (just loaded them 
all that I could as a test).

No other change to the INI file.

>btw, for what I can read in the screenshot, you are executing the
>php.ini :) Is it really what you want?

No, I'm not that idiot, and even if I did this, wouldn't php just ignore the file as it contains no php code?
May I ask why you think I'm executing php.ini?

From the screenshot it's clear that the error message refers to php.ini. Do you have the same error message in php.log? 


>(restarting IIS in between each change).

Did you make sure that no php-cgi.exe processes remained running?
Did you make sure that browser gets the content from executed script and IIS returned HTTP/200?

On the screenshot, bottom right: 
"PHP Deprecated: Comments starting with '#' are deprecated in  ..php.ini..."

That can happen only when php-cgi.exe php.ini is used.

Please try "php -c php.ini -i", and no, I do not consider you as an idiot (just in case :)

>On the screenshot, bottom right: 
>"PHP Deprecated: Comments starting with '#' are deprecated in 
>..php.ini..."
>
>That can happen only when php-cgi.exe php.ini is used

Funny :), but you're absolutely wrong here. Please check callstack that I submitted in the original post and you'll see that php was PARSING that php.ini file when it tried to throw an error and crashed. 

FYI php parses ini files too and there are lexer/grammars in 
Zend/zend_ini_parser.y and Zend/zend_ini_scanner.l

In fact php was run with a pure php file, but it does not matter because php did not even start compiling that file.

IIS crashes with this error:
============================================

FastCGI Error
The FastCGI Handler was unable to process the request. 
--------------------------------------------------------------------------------

Error Details:

The FastCGI process exited unexpectedly 
Error Number: -1073741819 (0xc0000005). 
Error Description: Unknown Error 
HTTP Error 500 - Server Error.
Internet Information Services (IIS)

============================================
if you have VC6's JIT debugger turned on, you'll be prompted to start debugging.

NOTE0:
Installed IIS6 is the one that came with XP. FastCGI is taken from http://php.iis.net/

NOTE1:
Don't restart IIS using its own restart function. This function won't unload php-cgi.exe processes, so they may not see changes in php.ini. Restart "World Wide Web Publishing" service, and make sure php-cgi.exe is not listed in the process list, otherwise kill it.

NOTE2:
Official php-5.3RC3 binary http://windows.php.net/qa/
VC6 x86 Thread Safe (2009-Jun-10 21:10:42) Zip [12.83MB]
sha1: f657b41f9035d0d2245a83bbdf65c5ce0767245a 
is crashing too.

NOTE3:
php.ini should contain a line commented with # terminated with EOL (either 0xD,0xA, or just 0xA)
for example:
========================
#somethign

========================

NOTE4:
what you try to run does not matter. For example you may want to try
<?php phpinfo(); ?>


Let know if you need any furhter info.

Quick note: If you use fastcgi, you don't need thread safe build, use NTS. And for php 5.3, use VC9 NTS builds, even faster/better.

yes, I know this and pointed to this fact in PHPCON 2003.

Anyway the trouble manifests itself.
As far as I understand, the problem is with initialization of the module context. It is not done at the moment when php core logs the error in php.ini ("deprecated stuff" in this case).
If I'm correct, initialization is initialization. NTS won't crash just because it does not allocate its context in the heap because it uses static data. Even if it works foryou, uninitialized data won't let you control the values. You either can not get the error in php's log or can't stop it from appearing.
Try to change fcgi_logging value (fastcgi.logging = ON and OFF) and see if the error appears or does not appear respectively.

I still do not undestand how you get this warning as it happens only when php is trying to compile a php src file, and not a php.ini.

I'd to try with fcgi TS and see if it crashes. However, I'd to say that it is not a stopping for 5.3 if it does. FCGI should not be used using the TS builds but NTS.

> I still do not undestand how you get this warning as it happens 
> onlywhen php is trying to compile a php src file, and not 
> a php.ini.

Sorry, seems you ignore all I posted :)
Php was initializing itself. It pefroms this initialization and reading/parsing php.ini everytime BEFORE running any php src files.
Please don't try to "understand", either learn code or ask experienced people :)

> I'd to try with fcgi TS and see if it crashes. However, I'd to say > that it is not a stopping for 5.3 if it does. 

I think it's up to PM.

> FCGI should not be used using the TS builds but NTS.

Really? Only because TS is sligtly slower? or what?
Did you manage to run NTS/VC9 build at all?
I does not work for me.
TS/VC6 works if there are # in php.ini. NTS/VC9 produces HTTP/500 and nothing else. I'll report this separately.

TS/VC6 works if there are # in php.ini
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I meant
TS/VC6 works if there is no # in php.ini

"Really? Only because TS is sligtly slower? or what?
Did you manage to run NTS/VC9 build at all? I does not work for me."

Yes, it works for me and almost the full IIS team as well.

"NTS/VC9 produces HTTP/500 and nothing else. I'll report this separately."

Be sure that you have the VC9 runtime installed. Best is to test it in cli first.

Thanks for notes :)
I'll report as soon as I find a way to reproduce the problem.
Quite unexpectedly VC9/NTS started working :)

Regarding VC6/TS | VC9/TS, did you manage to reproduce the crash?

Cannot reproduce it using the VC6/TS or VC9/TS.

Does it crash for you using php-cgi.exe -c php.ini -i?

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".