Description:
------------
A GPF was observed in line #737 in sapi\cgi\cgi_main.c:
if (!IS_ABSOLUTE_PATH(path, path_len)) {
real_path = tsrm_realpath(path, NULL TSRMLS_CC);
fault-> real_path_len = strlen(real_path);
path = real_path;
path_len = real_path_len;
}
Reproduce code:
---------------
1) Install PHP 5.3 for win32 (VC6) version (I have not tried the VC9 version).
2) Switch to the folder and type:
C:\PHP-5.3.0.WIN32
php-cgi.exe FOOBAR\FOOBAR.PHP
It doesn't matter if FOOBAR folder exist or not.
Under Windows XP, with Visual Studio installed, the JIT debugger appears. With the debug symbols avaiable, it shows the error location.
NOTE: I can not repeat this under Windows 2000, which tells me it is a RANDOM memory bug. Whatever the pointer has in memory.
Expected result:
----------------
A "No Input File Specified" (NO GPF)
Actual result:
--------------
Under Windows XP, with Visual Studio installed, the JIT debugger appears. With the debug symbols avaiable, it shows the error location.
NOTE: I can not repeat this under Windows 2000, which tells me it is a RANDOM memory bug. Whatever the pointer has in memory.

With this 5.3.1-dev binaries, source and debug symbols installed and running:
G:\files\php>cd php-5.3.1-dev-Win32
G:\files\php\php-5.3.1-dev-Win32>php-cgi foobar\foobar.php
the JIT debugger shows the same fault source location in sapi\cgi\cgi-main.c location with the path pointer of 0x0000000.
A NULL check should be done here, but the odds are very good that the massive 5.3 changes in the filename parsing is the origin of the problem.
I say that because bug #49039 was the original problem found and in the midst of resolving why that was happening by trying relative paths, this GPF was discovered.
So I might suggest both these bugs be lumped together because the odds are good resolved #bug 49039 will resolve this one as well. However, adding a NULL check here probably is not a bad idea.

I can't reproduce it here. Can you try with the vc9 builds please?
Btw, when using FCGI, you should use VC9 builds anyway, no matter which webserver you use.

[2009-07-23 20:24 UTC] sant9442 at gmail dot com

The report provided was with 5.3.1 VC9 build, the VC6 is not available in the snapshots.
> Btw, when using FCGI, you should use VC9 builds anyway,
> no matter which webserver you use.
Thats true, but we have a PHP extension and thus must support all PHP versions.
However, with the PHP team final (poor) decision for 5.3 to only support VC6 and VC9, and we don't have VS 2008 (VC9) and don't plan to get it. We have VC6, VC8 (2005) as we are investing on VC10 (VS 2010) instead of wasting time with VC9.
If there is a 'Lite" version of the VC9 express we will look at this further, but with 2010 currently in the labs we don't want to back track to VC9. Microsoft heard the concerns and VS 2010 promises to be the "new VC6" and resolves most, if not all, the VC7, VC8, VC9 related compatibility issues.
Until 5.3 issues with the command line is resolved in some official timely manner, at this point we will not recommend PHP 5.3.0 installation for our intranet web server (http://www.santronics.com) nor will release a production version of our PHP extension for it at this time.
thanks for your comments

Poor decision to drop a more than 10 years old compiler? You must be kidding.
About your extension, if you are serious about windows support you should have a MSDN subscription which gives you VC9 licenses along other tools. If it builds with vc8, it should build smoothly with vc9 as well. I can give you a hand if necessary.
About the bug itself, please try a recent snapshot, this bug has been fixed already (and it is not related to #49039 but #47318).

[2009-08-18 01:00 UTC] 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".