Please try using this CVS snapshot:

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

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

I just tested it with

PHP 5.3 - Windows x86 VC6 (thread safe))  [12.41MB] - 2009-Feb-23 08:00:00

and it still crashes...

By the way, the crash is confirmed by several other users:

http://lists.netfielders.de/pipermail/typo3-project-5_0-general/2009-February/001878.html

\php53vc6ts>php ..\php53snapvc9\47473.php

Warning: set_error_handler() expects the argument (ErrorHandler::handleError) to be a valid callback in C:\Users\pierre\Documents\test\php53snapvc9\47473.php on line 4


I suppose it happens in typo3 under certain conditions and not simply with the code you gave here. Please provide a full script to reproduce the crash.

Here you can download the source:
https://svn.typo3.org/FLOW3/Distribution/trunk/

Just the set your server to the "Public"-Directory.
And call e.g. http://localhost/ (you should see the welcome screen)
Than call http://localhost/Testing/ (should crash!!!)

The origin of the crash is located in in the constructor of Packages/Global/FLOW3/Classes/Error/ErrorHandler.php.

http://localhost/Testing/ -> Packages/Global/Testing/Classes/Controller/DefaultController.php

Please provide a small (or the smallest possible script) script to reproduce your problem.

Do not take it too badly but I do not have the time to fetch and install Flow3 (or any dependency).

We really need a self contained script to be able to efficiently fix this bug. It is easy to crash an app but not to create a small script, and as you know this app better than us... :)

By the way, the SSL certificate for this URL is not valid.

I'm not so deep in the development of the FLOW3-package. I'm just developing an other package. The main part is developed on linux or mac.

The constructor [1] is called twice and second time it seems to crash. But just calling it twice does not crash it.

Is there a php-function, which shows the content, which was set via set_error_handler()? I have not found one...

[1] http://forge.typo3.org/repositories/entry/package-flow3/trunk/Classes/Error/ErrorHandler.php

You can always try generating a backtrace of that crash yourself, instructions are here: http://bugs.php.net/bugs-generating-backtrace win32.php 

It's propably easier to accomplish with better tools like valgrind on any *nix system. Unless of course this happens only within win32 env.

It's just a problem on Windows Vista (and properbly on Windows XP):

So I have made the backtrace of the apache. The just using the php.exe does not work right now. (There is somewhere a bug in the CLI-version of the FLOW3-controller) So this one will follow, tomorrow. But for now:

PHP-Version: Wed Feb 25 09:04:13 2009  

apache__PID__4956__Date__02_25_2009__Time_10_26_11AM__627__Second_Chance_Exception_C0000005.dmp
Type of Analysis Performed   Crash Analysis 
Machine Name   ~...~
Operating System   Windows Vista Service Pack 1 
Number Of Processors   2 
Process ID   4956 
Process Image   ~\workspaces\flow3\xampplite\apache\bin\apache.exe 
System Up-Time   1 day(s) 01:42:07 
Process Up-Time   00:06:50 

Thread 240 - System ID 5404
Entry point   msvcr71!endthreadex+31 
Create time   25.02.2009 10:19:23 
Time spent in user mode   0 Days 0:0:2.59 
Time spent in kernel mode   0 Days 0:0:8.954 

Function     Arg 1     Arg 2     Arg 3   Source 
php5ts!zend_hash_apply+37     08702778     01aa0070     03d68fc0    
php5ts!zval_mark_grey+8c     08707b78     03d68fc0     769c9d32    
php5ts!gc_mark_roots+95     03d68fc0     769c9d32     0792fa54    
php5ts!gc_collect_cycles+64     03d68fc0     03d68fc0     00000013    
php5ts!zend_deactivate+12d     00000000     00000000     00000000    

PHP5TS!ZEND_HASH_APPLY+37In apache__PID__4956__Date__02_25_2009__Time_10_26_11AM__627__Second_Chance_Exception_C0000005.dmp the assembly instruction at php5ts!zend_hash_apply+37 in ~\workspaces\flow3\xampplite\apache\bin\php5ts.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x0000000d on thread 240

This is my first time with bug-backtrace. So, tell me, if there is something else to adjust, except from the manual.

I have include php like this in the apache:
LoadModule php5_module "~/workspaces/flow3/xampplite/apache/bin/php5apache2_2.dll"

Do you mean that you can't reproduce this bug on Linux/Unix (and thread safe SAPI)?

We still a self contained script to reproduce the problem.

No, on Linux it's running smoothly (with SAPI I don't know, but it should), because otherwise Robert or Karsten (Project-Leader) would already be in contact, what there a with other bugs.
It's just on windows, they using mac/linux.

It seems to be something like the length of a filename on windows with just 260 characters.

The first time the crash occured, switching from alpha1 to alpha2. In alpha3 it seems to be solved, because we thought it was connected to this bug [1] and it was not crashing anymore. In beta1 it was there again.

[1] http://bugs.php.net/bug.php?id=46241

I don't see why the max path lenght limit (which can affect other systems as well) is related to this backtrace.

Can you try it using a threaded SAPI under linux or using fastcgi on windows please?

The max path length is just an example, which is treated differently on the OS.

I have tried to setup fastcgi in my xampp installation. But I always get in 500 error. I tried the nearly every thing from google, but every where there seems to be missing something.

Do you have a complete example of including fastcgi in the apache-conf for windows?

On Max und Linux is working. So this is realy just a windows bug.

This is what I get:
C:\php-sdk\php53\vc9\x86\PHP_5_3>release\php 47473.php

Warning: set_error_handler() expects the argument (ErrorHandler::handleError) to be a valid callback in C:\php-sdk\php53\vc9\x86\PHP_5_3\47473.php on line 4

Notice: foo in C:\php-sdk\php53\vc9\x86\PHP_5_3\47473.php on line 9


using:

<?php
class ErrorHandler {
	public function __construct() {
		set_error_handler(array($this, 'handleError'));
	}

}
$a = new ErrorHandler;
trigger_error('foo');


Please provide a full working script to reproduce the crash. A full working script I can copy/paste and use it directly.

Please try with 5.3.0RC4 as well :)

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