Would anybody be kind to help me with any possible information on this error? causes? login? where to look/start?
Cannot use output buffering in output buffering display handlers in <**Unknown**> on line **0**
Example code:
function test($b) { return _strrev($b); }
ob_start("test");
echo "123";
ob_end_flush();
Information:
This is CentOS 6.7
This is PHP PHP 5.5.32 (cli)
This is NOT Wordpress
This is a simple PHP file with pseudo code (above)
No caching, no Varnish, no Nginx, no custom headers
Thanks
In an effort to make this question of some use to others I will summarise the comments section in the form of an answer.
It turns out that if you make a coding error in the callback function used by ob_start it generates this somewhat unhelpful error message
In testing I quite accidentally made a silly error while amending the callback funtion shown by the questioner, I coded
<?php
function test($b) {
return str-replace('2', 'XXX', $b);
}
ob_start("test");
echo "123";
ob_end_flush();
Note the misspelling of the str_replace() function.
This generated the error
Fatal error: Unknown: Cannot use output buffering in output buffering display handlers in Unknown on line 0
So it appears that PHP cannot report runtime errors in an ob_start callback funtion. Instead it must default to a generic error along the lines of Ouch that hurt
Maybe one of us should report this as a PHP Bug
After some more testing, this error senario produces a meaningful error in PHP 7.0.5
Notice: Use of undefined constant str - assumed 'str' in tst.php on line 3
Fatal error: Uncaught Error: Call to undefined function replace() in tst.php:3
so this may be fixed now, but all previous PHP versions i.e. 5.4 / 5.5 / 5.6 produce the unhelpful error message
Related
First of all, if it's relevant, this is in a session handler. This function is the one that writes to the database and is passed to session_set_save_handler along with my other functions like this
session_set_save_handler('sess_open', 'sess_close', 'sess_read', 'sess_write', 'sess_destroy', 'sess_gc');
I have this chunk of code...
$qid = "select count(*) as total
from zen_sessions
where sesskey = '" . $key . "'";
if(!class_exists('DB'))
require_once dirname(dirname(__FILE__)).'/class/DB.class.php';
var_dump(new DB()); //this is line 109
$total = DB::select_one($qid);
the conditional and var_dump are for testing. Oddly enough sometimes it works fine while others it gives me an error:
Fatal error: Class 'DB' not found in /path/to/file/session_functions.php on line 109
I cannot figure how this wouldn't crash at the require instead of the var_dump and why only sometimes?
Thanks in advance for any insight.
edit-- response to comment/question:
The result of the following code
var_dump(class_exists('DB', false));
var_dump(is_file(dirname(__DIR__).'/class/DB.class.php'));
is:
bool(false) bool(true)
before trying to require it and the same result after the require(or true true when it doesn't give me an error)
Looks something like:
bool(true) bool(true) object(DB)#3 (0) { }
The previous code chunk is the result about once out of every 5 page loads while the error is the result the other 4.
Edit2 -- new findings.
Even more curious is according to the manual I should never see these debugging statements or errors
Note:
The "write" handler is not executed until after the output stream is
closed. Thus, output from debugging statements in the "write" handler
will never be seen in the browser. If debugging output is necessary,
it is suggested that the debug output be written to a file instead.
Edit 3 - A Note for clarity:
The DB class Should have been autoloaded(and is everywhere else in the application) the class_exists and require are simply there for testing purposes.
Edit 4 - Stack trace
I decided to try and throw an exception when the class isn't found to see the stack trace, this is what I get
Fatal error: Uncaught exception 'Exception' with message 'DB Class Not Found.'
in /path/to/file/session_functions.php:108
Stack trace: #0 [internal function]: sess_write('074dabb967260e9...', 'securityToken|s...')
#1 {main} thrown in /path/to/file/session_functions.php on line 108
The only thing that I can think of that may be causing this, is from a notice in the PHP docs for session_set_save_handler:
Warning
Current working directory is changed with some SAPIs if session is closed in the script termination. It is possible to close the session earlier with session_write_close().
From what you are experiencing, I am guessing the current working directory is changed, so require_once doesn't find the file.
I would try adding session_write_close(); to somewhere in your function and see if that fixes it.
Admittedly, not sure why is_file would return true in this case, but maybe worth a shot.
Even though I can not be sure, but I bet that the error is somewhere else and it's just projecting itself as you've described it.
In order to test and debug your code, you need to use a debugger like PDT. But then the problem is that you need to debug a part of your code that is out of debugger's reach, the session writer! To overcome this problem you can use session_write_close. You can put it somewhere at the end of your bootstrap or if you don't have one, you can do it like this:
<?php
function shutdown_function()
{
session_write_close();
}
register_shutdown_function('shutdown_function');
Then by setting a break point, you can start debugging your session code from here. Let me know if I win the bet.
try:
$save_handler = new DB();
session_set_save_handler($save_handler, true);
then map read, write, etc functions inside your class. i faced a similar issue(bizarre random errors about a class not being found) implementing another user's custom save handler workaround for HHVM with redis, and this is how i fixed it. if you are using HipHopVirtualMachine (or possibly some other type of JIT compiler or app cache), sometimes your project can cache some functions without updating, producing odd errors like this. usually a restart of the fastcgi daemon and adding white space to one of your files is enough to force it to re interpret your project.
I use this to compile my java file
$command_compile = "javac $target_path_file 2>&1";
exec($command_compile, $compile_result, $return_compile);
And When my java file has syntax error. It always has error
Error: Could not find or load main class Myclass
How to get error such as Syntax Error. need ) On line 5
Thanks you
$res = exec($command_compile, $compile_result, $return_compile);
inside $res you get the last line of output of the executed command
If javac returns more lines (either error or informative messages) you may want to parse the $compile_result array that contains every output line.
foreach($compile_result as $compile_result_line) {
// do what you need with $compile_result_line
}
Anyway see http://php.net/function.exec for a detailed explanation of exec
The error you get is not from PHP code but is a "java" issue when you call javac. It seem you're trying to compile a file that reference an undefined class.
Everyone says that "Enabling errors to be shown" in an active site is bad (due to some security issues).
Now, we have to consider 2 cases:
The site is in debug mode
The site is not in debug mode
Now, for case #1:
We want to see the errors. How?
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 1);
Nothing more simple. Also we can customize an error handler for all errors except Parse and Fatal.
Instead, if the case is #2:
We would like to be able to deactivate the messages:
ini_set('error_reporting', 0);
ini_set('display_errors', 0);
And it's ok. But what about showing users a friendly message such as "Hei man, something is really f**ked up. I don't assure you we are working to fix it, since we are very lazy.".
You should enable errors again and just use the function set_error_handler() and hope that no parse or fatal errors occur. But my first question is:
Question 1: Is that possible to avoid error reporting and have a custom offline page that is loaded when something goes wrong? I mean, is it possible to have ini_set('error_reporting', 0); and ini_set('display_errors', 0); and still be able to tell PHP to load a custom Error page?
And now another:
Question 2: I developed a class that with the power of set_error_handler() logs errors occurred into the database. In this way I can keep track of hack attempts and other cool stuff. (And yes, i'm always sure the DB is accessible since my application shuts down if we cannot connect to the DB). Is this worth something?
Some time ago I created small system that redirects you to error page when fatal error occurs / uncaught exception was thrown. It was possible with assumption, that every request is handled by one file and ends in this file, so by reaching end of this file I'm sure that everything went OK. With this condition I've set up function to redirect on error page and registered it as shutdown function - so it will be called at the end of all requests. Now in this function I check conditions for clean shutdown and if hey are met, I do nothing and output is flushed to the browser, otherwise buffer is cleaned and only header redirecting to error page is sent.
Simplified version of this code:
<?php
function redirect_on_error(){
if(!defined('EVERYTHING_WENT_OK')){
ob_end_clean();
header('Location: error.html');
}
}
register_shutdown_function('redirect_on_error');
ob_start();
include 'some/working/code.php';
echo "Now I'm going to call undefined function or throw something bad";
undefined_function();
throw new Exception('In case undefined function is defined.');
define('EVERYTHING_WENT_OK', TRUE);
exit;
Question 1: Is that possible to avoid error reporting and have a custom offline page that is loaded when something goes wrong?
Unfortunately, I don't think so, at least for fatal errors. However, recent versions of PHP always send a 500 response when that occurs, so, depending on webserver, you may be able to rewrite the response if such thing happens. If your actual server running PHP is behind a reverse proxy, this becomes trivial with Apache.
Question 2: I developed a class that with the power of set_error_handler() logs errors occurred into the database.
Sure, it's always good to log the errors. You already seem to be aware of the limitations of logging errors into the database.
I have a eval function like this
if(FALSE === #eval($code)) echo 'your code has php errors';
So if the code has synthax errors it will return that message.
The problem is that if within the code you have something like:
require_once('missing_file.php');
it will just break the page, without my nice error message :(
Is there any workaround for this?
Well, first I hope that $code comes from a trusted source and that you're executing arbitrary code sent by the users.
Second, the only way I see you can workaround that is to save $code into a file, run it with the command line PHP interpreter, and check the exit value. Note that passing this test doesn't make $code fatal error free, it just so happened that this particular execution of the script did not throw any fatal error; there may be other code paths that trigger such an error.
This is because once eval triggers a fatal error, it can't be recovered and the script dies. eval only returns FALSE if there is a parsing error.
I would like to be able to discard a partially rendered page and show an error page in PHP.
I already know about set_error_handler(), but it can only trap certain types of errors. I would like to know how to show an error page when an error type which can't be trapped by set_error_handler() is raised.
Unfortunately, it seems that the following code, when run with PHP 5.3.2 on Apache 2.2, doesn't do what I would expect it to do:
<?php
// Start the output buffer
ob_start();
// Output something into the buffer.
// I only want this to be displayed if I call one of the
// ob_flush functions or echo the buffer myself later.
echo "yep";
// Call a function I know not to exist in order to raise
// an error which cannot be trapped by set_error_handler()
// and would, if display_errors was On, output "Fatal
// error: Call to undefined function fwee()..."
function_which_does_not_exist();
// This will never be executed.
$out = ob_get_clean();
The output of the script is:
yep
Whereas I would expect it to output nothing (or spew error info and only error info if display_errors() is on).
I have confirmed using LiveHTTPHeaders that PHP 5.3.2 does send a 500 error to the browser when display_errors is off (and a 200 when it's on) using the version of apache supplied by MacPorts, but it only ever spits 200s when using PHP 5.3.1 on XAMPP.
I tried setting ErrorDocument 500 "test" in the apache configuration (confirmed to be working by doing the same for 404) but PHP never shows the custom error, even when the entire contents of the script is just header('HTTP/1.1 500 Internal Server Error');
I'm not sure what else to do to make sure a partially rendered page is replaced with a simple error.
I can also confirm that this happens in the Yii framework. If I edit the view for the "about" page in the blog demo to have a line which reads <?php echo function_which_does_not_exist() ?>, I get a partially rendered page.
You could pass ob_start the name of a callback function, that is executed before the output is flushed on ob_get_clean().
This callback function seams to be executed even if an error occured on the page.
This way you could do something like this:
<?php
$endReached = 0;
function outpu_cb($buffer) {
global $endReached;
if ($endReached) return $buffer;
else return 'Your error message';
}
// Start the output buffer
ob_start('outpu_cb');
// Output something into the buffer.
// I only want this to be displayed if I call one of the
// ob_flush functions or echo the buffer myself later.
echo "yep";
// Call a function I know not to exist in order to raise
// an error which cannot be trapped by set_error_handler()
// and would, if display_errors was On, output "Fatal
// error: Call to undefined function fwee()..."
function_which_does_not_exist();
// This will never be executed.
$endReached = 1;
echo ob_get_clean();
?>
I think the only right way to do this is by using correct output buffering, than you don't have to rely on specific webserver or browser behaviour.
Best you'd use a MVC framework to handle this for you. All output is buffered until all systems are go, so when an error occurs you can take another route, clear the current buffer and display some nice error message.
You can also use the ob_*() family of functions.
You have to call ob_start() as the very first thing in your script (well, before any output is generated)
Install an error_handler to fetch errors
When an error occured, clean the buffer and re-route your app logic to display some nice userfriendly error message
If your talking about E_FATAL or other such errors yes you can catch them with a custom error handler using set_error_handler().
All you need to add is a shutdown function.
// Set the error handler
set_error_handler(array('error', 'handler'));
// Catch E_FATAL errors too!
register_shutdown_function(array('error', 'catch_fatal'));
// Set the exception handler
set_exception_handler(array('error', 'exception'));
// Manually return a new exception
function catch_fatal()
{
if($e=error_get_last())Error::exception(new ErrorException($e['message'],$e['type'],0,$e['file'],$e['line']));
}
Take a look at http://micromvc.com or http://kohanaphp.com/ to see how it's done.
An old question, but for the record I'd suggest avoiding this issue rather than handling it.
My own approach is to build the response in a response object rather than echoing it as you go along, and only echo the output once the full response has been processed without error. This requires a template system that parses your template and builds your response into a string, in contrast to a classic PHP template which echoes output from your placeholders.
This way you entirely avoid PHP's crufty management of the output cache in error states.