I'm sharing this issue, because it is a particularly tricky type of coding problem to resolve.
I've several in the past gotten an error saying:
This page isn’t working
website.com didn’t send any data.
ERR_EMPTY_RESPONSE
Which is different than what Symfony displays when there is an error in the code producing a webpages for the site, so isn't all that helpful.
This time I tracked down the cause of the error by setting breakpoints, not in the code that I was editing, because the php xdebugger never got that far, but deep in the Symfony code that runs before my code actually gets executed. Here is the code in which I put the breakpoint:
public static function handleFatalError(array $error = null)
{
if (null === self::$reservedMemory) {
return;
}
self::$reservedMemory = null;
$handler = set_error_handler('var_dump');
$handler = is_array($handler) ? $handler[0] : null;
restore_error_handler();
if (!$handler instanceof self) {
return;
}
if ($exit = null === $error) {
$error = error_get_last();
}
try {
while (self::$stackedErrorLevels) { <<<< I put the breakpoint here!
static::unstackErrors();
}
} catch (\Exception $exception) {
// Handled below
} catch (\Throwable $exception) {
// Handled below
}
if ($error && $error['type'] &= E_PARSE | E_ERROR | E_CORE_ERROR | E_COMPILE_ERROR) {
// Let's not throw anymore but keep logging
$handler->throwAt(0, true);
$trace = isset($error['backtrace']) ? $error['backtrace'] : null;
if (0 === strpos($error['message'], 'Allowed memory') || 0 === strpos($error['message'], 'Out of memory')) {
$exception = new OutOfMemoryException($handler->levels[$error['type']].': '.$error['message'], 0, $error['type'], $error['file'], $error['line'], 2, false, $trace);
} else {
$exception = new FatalErrorException($handler->levels[$error['type']].': '.$error['message'], 0, $error['type'], $error['file'], $error['line'], 2, true, $trace);
}
}
try {
if (isset($exception)) {
self::$exitCode = 255;
$handler->handleException($exception, $error);
}
} catch (FatalErrorException $e) {
// Ignore this re-throw
}
if ($exit && self::$exitCode) {
$exitCode = self::$exitCode;
register_shutdown_function('register_shutdown_function', function () use ($exitCode) { exit($exitCode); });
}
}
When Symfony tries to load my bundle file with a require $file
statement in another part of its code, the above function is called. Unfortunately, I couldn't watch the $error or any other variable, but when the breakpoint was encountered, my debugger does show the content of the $error variable up on the line where it is assigned the value of error_get_last();. Even though the content is an array so extends beyond the right edge of my screen, it displays enough to make out the problem. No line number shows, but the text of the error does.
Another thing that I found while looking for the error is that all of the PHP files in the server's src/AppBundle./Controller/
and below are processed by Symfony, so if you keep your code in files ending with *.php it will be loaded, even though it isn't referenced by your code. In my case I had a bundle file that I renamed from bundle.php to bundle.24.php, intending to keep it as a fallback while I continued working on new changes to bundle.php, but bundle.24.php had a syntax error, which stopped Symfony from loading the project, but I wasn't aware of this because I got the error that I showed at the top of this issue.
Anyway, I thought I'd share this with anyone who runs into the same error while working with Symfony v2.8. I hope that later versions of Symfony don't continue to work this way, but if they do, well then here is a clue to where to look or what might be causing the problem. Note, in later versions, I'm sure that the handler function could be different than what I'm showing, but it should be some what similar.
Good luck.
The solution when you get this kind of error in Symfony is to place breakpoints in the code that is called by the app_dev.php's $response->send(); line, and then walk the code until you fine the require $file;
line. Use the your PHP debugger to watch the $file and $class variables and you'll see that the require statement is about to load your code file. If it jumps to the error handler function, you'll know that the code didn't load, and as I said in the issue, you won't be able to watch the $error variable, but you should be able to see its contents as I described, so have a pretty good idea of the code error that is causing the bundle file to not load.