|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #64924 500 internal server error caused by PHP but nothing logged in error log
Submitted: 2013-05-27 01:47 UTC Modified: 2013-05-27 15:07 UTC
From: matteosistisette at gmail dot com Assigned:
Status: Not a bug Package: *Web Server problem
PHP Version: 5.4.15 OS: ubuntu 12.10
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: matteosistisette at gmail dot com
New email:
PHP Version: OS:


 [2013-05-27 01:47 UTC] matteosistisette at gmail dot com
I have no idea what's triggering this, certainly some error of mine in my php 
code, however, in very rare cases I'm getting 500 internal server errors which 
are logged as such in apache's access_log, but don't log ABSOLUTELY ANYTHING in 
PHP's error log, not even a fatal error or parse error.
I only get an empty 500 response from the server.

Such a thing must never, ever, ever happen, no matter what, if the error is 
caused by php code.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-05-27 01:52 UTC] matteosistisette at gmail dot com
And this is even at runtime!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Part of my code gets executed, and then the 500 error is produced.
I even have an error handler that prints a stact trace, and doesn't work in this 
case, so the error is fatal or anyway unhandable.
However it should ALWAYS show up on error log with an error message.

This is unbelievable.
 [2013-05-27 06:19 UTC]
-Status: Open +Status: Feedback
 [2013-05-27 06:19 UTC]
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 for *NIX and 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.

 [2013-05-27 10:37 UTC] matteosistisette at gmail dot com
Apparently my php is configured with --disable-debug.
How do I get a debug-enabled version?
 [2013-05-27 10:41 UTC] matteosistisette at gmail dot com
It seems too damn complicated to get a backtrace.
Php (and any program for that matter) should be built in such a way that if it 
crashes, there would be a file somewhere ready to pick!
 [2013-05-27 11:19 UTC] matteosistisette at gmail dot com

What is triggering the crash is this code:

  $info="SELECT offset,height FROM segment ORDER BY id DESC limit 1";

Obviously the code is screwed up (I use the query string as if it was the result 
from a query!!) but it's crashing PHP instead of triggering an error.

Curiously enough, though, this only happens inside the true intricated code and 
not if isolated.
Anyway I can 100% assure these are the lines of code that trigger the crash
 [2013-05-27 14:01 UTC]
I really doubt this is crashing PHP. I would have a look at any custom error 
handler you have in place and look at what it does with Illegal Offset warnings. 
This is a new warning in PHP 5.4 which you get if you try to use a string as if 
it was an associative array, since this is what you are doing in this case.
 [2013-05-27 14:31 UTC] matteosistisette at gmail dot com
Good catch.

It's almost certainly the error handler.

However, while I try to paste the code here, this broken bugtracker keeps 
rejecting it as spam.
 [2013-05-27 14:32 UTC] matteosistisette at gmail dot com
It's unbelievable. I can post any sort of stupid blah bla blah, but if I try to 
paste a snippet of code it rejects it at spam.
 [2013-05-27 14:32 UTC]
-Status: Feedback +Status: Not a bug
 [2013-05-27 14:32 UTC]
 [2013-05-27 14:33 UTC] matteosistisette at gmail dot com
spam spam spam spam spam spam spam spam spam spam spam 

Now my next comment will be the code, which is valuable information to fix the 
bug, but it won't let me post it
 [2013-05-27 14:44 UTC]
There is no bug. Your custom error handler is explicitly sending a 500. We do not 
need to see it.
 [2013-05-27 14:49 UTC] matteosistisette at gmail dot com
No man, my error hanler sends a 500 AND prints a stack trace.
I've had thousands of errors in my code before, and my error handler correctly 
printed a stack trace.

And if there was an error in my error handler, then the PHP error should be 
normally logged in the error_log. NOTHING is logged in the error_log, that seems 
to indicate PHP is crashing.
No matter how bad is my error handler, if it crashes PHP there's a bug in PHP
 [2013-05-27 14:50 UTC] matteosistisette at gmail dot com
And you definitely do need to see it before you can say what you are saying
 [2013-05-27 15:07 UTC] matteosistisette at gmail dot com
I'll try to post the error handler replacing the [at] character with [at] (you 
get what I mean), let's see if that is what bothers the antispam...

set_error_handler(function($errno, $errstr, $errfile, $errline){
    header("Content-Type: text/plain");
    $output="$errstr \n [at] $errfile($errline)\n";
    foreach ($backtrace as $i=>$item) {
        if ($i>0) $output.= "#$i. [at] ".$item['file']."
(".$item['line']."): ".(isset($item['class'])?
 [2013-05-27 15:11 UTC] matteosistisette at gmail dot com
However, the isolated string offset error alone does not trigger the crash, it 
gets stack-traced correctly by my error handler.

The same error inside a stack of method calls triggers the issue. Unfortunately I 
haven't been able to isolate a minimal code that will let you reproduce the 
issue, I do can reproduce it 100% systematically but with complex code + database 
and complicated sequence of steps of which I have no idea what is relevant to the 
 [2013-06-01 15:26 UTC] matteosistisette at gmail dot com
Why hasn't this been reopened yet?
 [2013-09-23 14:01 UTC] andrew_lz at poczta dot fm
I have similar situation caused by Error Control Operator (@). If you have 2 scripts e.g. a.php and b.php. b.php will generate fatal error (in my case non existing required file). If you include b.php in a.php using error control operator (@include 'b.php';) a.php will fail and trace will not be saved to log file.

echo "Script A";
@include 'b.php';

require 'not_existing_file.php';
echo "Script B";
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jul 14 08:01:28 2024 UTC