It would help to have the "evil" script.

If you use FastCGI, you do not need the thread safe version, please try using the NTS builds (vc9 too).

Ok, I've parsed it with:
VC9 x86 Non Thread Safe (2009-Mar-24 15:00:00)

    * Zip [12.73MB]
      sha1: 9c94f8a7cdc73c22da8c66e6af16ade4ceb4d197 

Result:
CGI / FastCGI has encountered a problem and needs to close.  We are sorry for the inconvenience.


This means same thing is happening.

Only one line of code is responsible for it.
Commenting it out, makes no crash at all.

Line of code is:

$temp .= $site->p('You will receive ' . $amount . ' ' . $mon . ' to ' . $dc . ' account with number ' . $acc, array('class'=>'phys_wide face_green') );

HINT:
When I "shothened"(removed letters), first or second arg of 'p' method it worked!

Like:
$temp .= $site->p('You will receive ' . $amount . ' ' . $mon . ' to ' . $dc . ' account number ' . $acc, array('class'=>'phys_wide face_green') );
Works without crash!

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

I..., m..., well.
Hmmmmm...!?

This script uses custom classes that I've built and needs to be loaded.

Anyway... I've found out, that crash occurs in LAST line of code before PHP's closing tag ?>


new face($cont);


There are 2 ways od avoiding crash.
a) By commenting out // new face($cont);
b) By making string $cont supplied to class face shorter then 2232 letters

I can not just post / give you all code, as this script is being built for financial biz. So it is a secret.

Crash occurs inside object of 'face' class.

What do you propose?

Create the smallest possible script to reproduce the problem and post it here.

Script has 145 lines of code and loads 5 custom classes and 3 extra files.

What you propose is, as I've just found, most likely impossible.
Reason is that crash won't appear if I remove ANYTHING from script.

At one line I removed COMMENT!
// From DB....

Which doesn't affect PHP's code in ANY way.
To my shock everythhing restored to normal.

Exactly this fact makes me unable to ISOLATE few lines of code for crash reproduction.

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.

And how we suppose to know what you are doing then?

You can try to create a backtrace, maybe there is an obvious problem which can be seen in it.

Ok, I will make a backtrace then and post it here.
But until I do it, this is last what I found out:

Remember comment line:
// From DB....

Well if I remove JUST one dot it becomes:
// From DB...
and NO crash occurs!!!

If I ADD just one dot it becomes:
// From DB.....
and NO crash occurs!!!

What does it tell you, at a first glance?
I think, that it is, a specific number of string symbols, in .php file that represent PHP(code) script itself, that brings core down

Thread 0 - System ID 1888Entry point	  php_cgi+61ea
Create time	  25.3.2009 23:08:05
Time spent in user mode	  0 Days 0:0:0.46
Time spent in kernel mode	  0 Days 0:0:0.78



Function	    Arg 1	    Arg 2	    Arg 3	  Source
php5!lex_scan+2c06	    00c0c8e4	    00000001	    0000002f	  
php5!zend_register_auto_global+7f	    00000000	    00000000	    00000000	  



PHP5!LEX_SCAN+2C06WARNING - DebugDiag was not able to locate debug symbols for php5.dll, so the information below may be incomplete.

In php-cgi__PID__2540__Date__03_25_2009__Time_11_08_11PM__531__Second_Chance_Exception_C0000005.dmp the assembly instruction at php5!lex_scan+2c06 in D:\Program Files\php\php5.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x02461000 on thread 0Module Information
Image Name:	D:\Program Files\php\php5.dll	  Symbol Type: 	Export
Base address:	0x10000000	  Time Stamp: 	Tue Mar 24 15:58:10 2009 
Checksum:	0x0055c816	  Comments: 	
COM DLL:	False	  Company Name: 	The PHP Group
ISAPIExtension:	False	  File Description: 	PHP Script Interpreter
ISAPIFilter:	False	  File Version: 	5.3.0RC2-dev
Managed DLL:	False	  Internal Name: 	PHP Script Interpreter
VB DLL:	False	  Legal Copyright: 	Copyright ? 1997-2008 The PHP Group
Loaded Image Name: 	php5.dll	  Legal Trademarks: 	PHP
Mapped Image Name: 		  Original filename: 	php5.dll
Module name: 	php5	  Private Build: 	
Single Threaded: 	False	  Product Name: 	PHP
Module Size: 	5,45 MBytes	  Product Version: 	5.3.0RC2-dev
Symbol File Name: 	php5.dll	  Special Build: 	&

Thread 0 - System ID 7056Entry point	  php_cgi+61ea
Create time	  29.3.2009 1:37:02
Time spent in user mode	  0 Days 0:0:0.0
Time spent in kernel mode	  0 Days 0:0:0.93



Function	    Arg 1	    Arg 2	    Arg 3	  Source
php5!lex_scan+2c06	    00c0c8e4	    00000001	    0000002f	  
php5!zend_register_auto_global+7f	    00000000	    00000000	    00000000	  



PHP5!LEX_SCAN+2C06WARNING - DebugDiag was not able to locate debug symbols for php5.dll, so the information below may be incomplete.

In php-cgi__PID__6828__Date__03_29_2009__Time_01_37_08AM__796__Second_Chance_Exception_C0000005.dmp the assembly instruction at php5!lex_scan+2c06 in D:\Program Files\php\php5.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x02461000 on thread 0Module Information
Image Name:	D:\Program Files\php\php5.dll	  Symbol Type: 	Export
Base address:	0x10000000	  Time Stamp: 	Tue Mar 24 15:58:10 2009 
Checksum:	0x0055c816	  Comments: 	
COM DLL:	False	  Company Name: 	The PHP Group
ISAPIExtension:	False	  File Description: 	PHP Script Interpreter
ISAPIFilter:	False	  File Version: 	5.3.0RC2-dev
Managed DLL:	False	  Internal Name: 	PHP Script Interpreter
VB DLL:	False	  Legal Copyright: 	Copyright ? 1997-2008 The PHP Group
Loaded Image Name: 	php5.dll	  Legal Trademarks: 	PHP
Mapped Image Name: 		  Original filename: 	php5.dll
Module name: 	php5	  Private Build: 	
Single Threaded: 	False	  Product Name: 	PHP
Module Size: 	5,45 MBytes	  Product Version: 	5.3.0RC2-dev
Symbol File Name: 	php5.dll	  Special Build: 	&

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Pretty sure this was fixed on Wednesday / Thursday.

I have just used lattest windows snapshot of VC9 x86 Non Thread Safe.

Bug is still present, so crash still occurs.

And my answer to your templated request is above at:
[25 Mar 1:16pm UTC] ipseno at yahoo dot com

I've just downloaded latest 5.3.0RC2-dev, Build Date: Apr 5 2009 22:55:43 
Crash still occurs, by returning 500 Internal server error.

Here is a brand new Crash report that gives best info so far...


Thread 0 - System ID 3192Entry point	  php_cgi!mainCRTStartup
Create time	  6.4.2009 0:16:56
Time spent in user mode	  0 Days 0:0:0.0
Time spent in kernel mode	  0 Days 0:0:0.78



Function	    Arg 1	    Arg 2	    Arg 3	  Source
php5!lex_scan+2c26	    00c0c8e4	    00000001	    0000002f	  
php5!zendlex+2f	    00c0c8dc	    00c0deac	    00fdce30	  
php5!zendparse+15a	    00fdce30	    00000002	    00000040	  
php5!compile_file+b0	    00c0deac	    00000008	    00c0cc48	  
php5!phar_open_from_filename+2d6	    00c0deac	    00000008	    00c0deac	  
php5!zend_execute_scripts+4e	    00000008	    00000000	    00000003	  
php5!php_execute_script+1c8	    00c0deac	    0040a4f0	    00000001	  
php_cgi!main+ab0	    00000001	    00dc2be8	    00dc3080	  
php_cgi!memset+160	    00000000	    00000000	    7ffdf000	  
kernel32!BaseProcessStart+23	    004061ea	    00000000	    00000000	  



PHP5!LEX_SCAN+2C26In php-cgi__PID__4564__Date__04_06_2009__Time_12_17_03AM__46__Second_Chance_Exception_C0000005.dmp the assembly instruction at php5!lex_scan+2c26 in D:\Program Files\php\php5.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x02331000 on thread 0Module Information
Image Name:	D:\Program Files\php\php5.dll	  Symbol Type: 	PDB
Base address:	0x10000000	  Time Stamp: 	Sun Apr 05 23:56:26 2009 
Checksum:	0x00550f1f	  Comments: 	
COM DLL:	False	  Company Name: 	The PHP Group
ISAPIExtension:	False	  File Description: 	PHP Script Interpreter
ISAPIFilter:	False	  File Version: 	5.3.0RC2-dev
Managed DLL:	False	  Internal Name: 	PHP Script Interpreter
VB DLL:	False	  Legal Copyright: 	Copyright ? 1997-2008 The PHP Group
Loaded Image Name: 	php5.dll	  Legal Trademarks: 	PHP
Mapped Image Name: 		  Original filename: 	php5.dll
Module name: 	php5	  Private Build: 	
Single Threaded: 	False	  Product Name: 	PHP
Module Size: 	5,45 MBytes	  Product Version: 	5.3.0RC2-dev
Symbol File Name: 	D:\Interport\php-debug-pack-5.3-nts-win32-VC9-x86-latest\php5.pdb	  Special Build: 	&

Thansk for the backtrace, I still need a script to reproduce the problem. Or can you give me access to this box or to the app you use? The crash looks weird, in the lexer.

I've installed same OS on a new box, with sam Apache and PHP and Mysql ver.s and confs

Then I've put only "that" .php file in Apache dir and parsed it with php-cgi.exe

Crash occurred immediately! So now I know, that cause, is not from some custom configurations or some safety software or any other third party software.

Next, VERY GOOD part, is that even that file requires() few external files and objects, on that testing server I did not "gave them" to the script, because I've found out, that crash occurs, before any inclusion occurs, that is....  crash occurs at a core of PHP's startup.

This means I can send you an "evil" script, as I don't need to give you protected classes.

But you must promise, you will destroy it and erase it permanently after you are "done".

Perhaps if that PHAR thing is removed it works fine?

Sorry, but the script you sent me does not help. It still requires other files and is not really small.

For what I can see the DB connection is done at this stage as well. That brings me to one common problem:

- Which mysql version do you use? (server)

MySQL server is: 5.1.33, but 2 dayys ago it was 5.1.30
I tested script with both versions and crash occured.

I am confused, with your questions about phar and mysql.

I've told you, that on a new box with fresh WinXP SP3, and all updates. I've installed Apache 2.2.11 and PHP 5.3.0RC2-dev

Then parsed it(bug.php->which was the ONLY .php file on that server, so there was nothing to include() || require() or load in any way) by typing it's location in URL of browser which depends on apaches config: Ie: https://127.0.0.15/bug.php

IMPORTANT!!!
Do not parse it by means of mod_php! But as fcgid! -> Server API CGI/FastCGI 

I use in apache's config:
LoadModule fcgid_module modules/mod_fcgid.so

ScriptAlias /php5 "D:/Program Files/php/php-cgi.exe"
Action application/x-httpd-php /php5

AddType application/x-httpd-php .php5 .php4 .php .php3 .php2 .phtml .png

DirectoryIndex index.php index.html index.htm


You must receive:
CGI / FastCGI has encountered a problem and needs to close.  We are sorry for the inconvenience.
An then:
500
Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, webmaster@exchanger.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Be sure to use the libmysql.dll from the PHP releases and not the 5.1.30 DLL. Check your PATH environment, the php directory must be first in the list.

Done. Restarted. And same crash occurs.

Listen...
Can you confirm that bug.php crashed yours php-cgi.exe?
And after editing file by means of removing any symbol or adding one, "fixes" it?

No, I can't reproduce it. Without the script you are using, there is also no chance to actually reproduce your problem. Btw, out of curiosity, how large are the files used by the script? and the script itself?

Custom reusable objects:
354 KB (362.642 bytes)
464 KB (475.136 bytes)

Script:
450 KB (461.662 bytes) - Size
620 KB (634.880 bytes) - Size on disk
..., without images, temp and notes.

Second box has only Apache installed and PHP (NO Mysql at all !!)
And ONLY that, ONE file.
So it can't possibly include or require anything.

And error is reproduced at both boxes.

PS: Trace is from first box, that has all in it.

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

After updating to PHP Version 5.3.0RC4-dev, bug has disappeared.
Parsing bug.php resulted in Warning: require_once(... and Fatal error: require_once() [function.require]: Failed opening required ..., which means all is well now.

not a bug then > bogus

Crashed occurred through all versions of PHP 5.3 (alpha, beta, RC,1,2,3), on more then one machine.
In RC4 it has been fixed, so changes in RC4's sources fixed it.
It doesn't mean it is bogus

If it works with RC4 thi bug is not valid. There is no commit specific to this issue and can't be referenced as 'closed'.