Parse Error: Crashing Apache? - PHPUnit

[phant0m]

Hi

 

My Apache crashes when I have a PHP file with bad syntax during a PHPUnit test.

Does anyone know how I can stop Apache from crashing and have the test fail instead?

[Mchl]

How do you know Apache is crashing?

Isn't PHPUnit supposed to be run from CLI? So why is Apache even involved?

[phant0m]

I am trying to integrate PHPUnit into my framework. That's why Apache is involved. Everything works fine as long as all the files that are parsed while PHPUnit is running are without syntax errors.

 

Apache is crashing because I get a nice dialogue telling me "Apache HTTP Server has stopped working"

 

If the very same file with the same syntax error is included at an other time, I get the usual Syntax error message.

[Mchl]

What does Apache error log say?

[phant0m]

[sun Jun 13 14:13:16 2010] [notice] Parent: child process exited with status 3221225477 -- Restarting.

[phant0m]

Hmm... now it crashes on all syntax errors.

 

I have a custom error handler. When I disable that, Apache doesn't crash anymore.

However, the error_handler is not responsible for parse errors, right? So it shouldn't have an effect.

[phant0m]

So... here's a little summary and new insights into the problem.

 

Scenario: Bad Syntax in one of my PHP files.

What happens? Apache crashes, no output.

Apache's log: Parent: child process exited with status 3221225477 -- Restarting.

 

I have a custom error handler and I have a custom exception handler.

 

    function my_exception_handler($exception){
            chdir(XCMS_Config::SCRIPT_PATH);
            $file = fopen('log.log', "a+");
            fwrite($file, $exception->getMessage());
            fclose($file);
            echo Exceptions_Wrapper::getFullLogMessage($exception);
    }

 

When I comment the "echo" line, everything works as expected: I get the default PHP Parse error message.

However, when this line is there, the phenomenon described above happens.

If I exchange the line in question with a simple echo "test"; I get the usual PHP parse error and the string "test" on a new line AFTER the parse error.

 

Next thought: There is something fishy with the code inside the static method that is called.

:arrow: I have commented all the code inside that method: No effect. Apache still crashing.

I reckon that this means, that the method is not even invoked.

I use autoloading to load all my classes. Whatever other error or exception occurs, the Exception_Wrapper is always loaded without any problems. Only in this case it fails.

 

Then I have added this code to dump the errorMessage into a log file.

Result:

Unknown: Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively

 

Consequently, I have used ini_set to et bug_compat_42 to off. Result: Everything works fine now.

It turns out I have skipped some session handling for testing purposes. When I reactivate that part, it always works no matter what bug_compat_42 is set to.

 

What happens in that part:

I have a User object that pulls some information of $_SESSION['user'] into ->user, or creates it if it's not in the session.

It is a simple array with the settings of the user.

At the end, in __destruct, I write that information back into the session, so that I still have my settings the next time.

In the global context, I have a variable called $user that holds an instance of the User class.

A while ago, I was struggling with PHP crashes because register_globals was messed up, and as a result it would store the entire $user in $_SESSION['user'] resultint in unpredictable behaviour. I have a function that reverses the effects register_globals if it's switched on, and never had a problem since then. Anyway, register_globals is disabled on my test environment, so it has no effects. The problem described above only occured WITH register_globals.

 

Also, let's not forget that this new problem only occurs, when I don't do any session handling. (I know that session_register causes this message usually, but it is not to be found in my code)

And the notice in the quote above, ONLY appears on a syntax error.

 

I just can't see the connection between all of this :S

[phant0m]

any thoughts?