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.

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.

Apparently my php is configured with --disable-debug.
How do I get a debug-enabled version?

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!

SUPER LOL

What is triggering the crash is this code:

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

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

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.

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.

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.

.

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

There is no bug. Your custom error handler is explicitly sending a 500. We do not 
need to see it.

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

And you definitely do need to see it before you can say what you are saying

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){
    http_response_code(500);
    header("Content-Type: text/plain");
    $backtrace=debug_backtrace();
    $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'])?
$item['class']:'')."::".$item['function']."(".(is_array($item['args'])?
[at]implode(",",$item['args']):'').")\n";
    }
    die($output);
});

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

Why hasn't this been reopened yet?

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.

a.php:
<?php
echo "Script A";
@include 'b.php';

b.php:
<?php
require 'not_existing_file.php';
echo "Script B";