A PHP script is using the ZipArchive class and is potentially long running.
Since it is dying silently but writing a partial zip file, I wrapped error_log() statements around the $zip->close(). (ini_set sets error logging to a file and E_ALL just before this code)
error_log("calling zip->close()");
$rc = $zip->close();
error_log("zip->close() returned $rc");
The logging file shows the first error_log, but never the second.
A unix top command shows the process running for a total CPU time of c. 2.5 minutes before it goes defunct.
I have also tried trapping the error with set_error_handler(), and the handler using error_log() to record the catch. But nothing shows up in the log file.
I'm assuming the process is being bounced, maybe by Apache (I have no control over Apache or PHP).
My question is: why can't I see this error in the file being used by error_log?
Thanks for the suggestions for circumventing the problem, but my question remains:
Why can't I see this error in the log? Or why can't I catch this error via set_error_handler()?
set_time_limit(0);
0 = Indefinitely
Related
i got a script which creates a list implementation of messages being sent between users.
Everything works fine, till the amount of messages rises up to about 77.000.
For every message a object will be created and every object has a reference to the next message object.
I enabled error reporting and increased the memory limit - I don't get any errors and the http status code is a 200 Ok, even if the developer console tells me that the request failed.
If you have verified that it is not a memory limit issue, this could be a limitation of PHP....similar to this question:
How to Avoid PHP Object Nesting/Creation Limit?
If you need to work with 77 000 objects in the same PHP script - it is something wrong with the architecture, php is not right choice for such calculations (even if it can handle this under some circumstances)
to track this particular error try to set in php.ini:
display_errors=1
display_startup_errors=1
error_reporting=-1
log_errors=1
memory_limit=to any reasonable value
max_input_time=to any reasonable value
max_execution_time=to any reasonable value
report_memleaks=1
error_log=writable path
consider using xdebug extension
don't forget to restart apache after changing proper php.ini (you can have different php.ini for apache and cli)
check if any set_error_handler or set_exception_handler functions are called in your code
I have a web app that allows the user to upload a pdf and it will then email it to us via swiftmailer. With some pdfs, the process fails.
I can verify that it crashes the php script, yet returns no php error. There's a 500 error from the server, but normally if there's a 500 error, php has a log of what the error was.
I have also verified that it crashes at the
$mailer->send($message);
line
Oddly, only some pdfs crash it, and those same pdfs work fine on the development server with identical code.
What could be causing php to crash without an error message?
After running several tests, I found that error logging was happening some of the time, but not others. I didn't figure out why that was so, however, I tried renaming the php-errors.log file so php would start with a new, fresh log file, and now errors are getting logged properly. I don't know why that worked, but I'll take it.
FYI, I've run into two things that can cause a PHP crash without an error message:
Script timeouts - A timeout may prevent an error message from being returned; in my particular case the script was waiting for an SMTP response when the timeout happened, which may have been why I didn't get a timeout message. Try changing your max_execution_time value in php.ini to 300 (5 minutes) and see if you can get an actual error message.
Folder permissions - I've encountered a case where insufficient folder permissions resulted in the script just halting without providing an error.
In the case of 2, I wrapped a try/catch clause around the line that was causing the halt, and I finally got an Exception to show up explaining about the permissions problem. That may be worth trying as a general response to silent crashes.
Im running a long php script which handles large amounts of data.
The problem is that the script suddenly stops and no exception is thrown or could be found on the error_log.
I have set the display_errors and the error_logging to 1 in the .ini config file.
Few more details:
1) The scripts executes the 'file_get_contents' function for many times.
2) The scripts contains recursion when the file_get_contents fails.
Any help would be appriciated.
It might have hit the max execution time.
set_time_limit(0); // to increase the timelimit to infinity
Error loging configs are different depending on your hosting environment. I'd first verify that you're editing the right php.ini file. Take a look at your phpinfo output and make sure that those params are indeed set and check the path/file for where errors are being logged to. Sometimes it goes to the apache error log, other times it can be sent to a dedicated php log. Are you able to get any error output if you purposefully create a syntax error? You might also consider looking in your syslog to see if there's anything there.
I'm working on a large (inherited) codebase in PHP, and the error Exception thrown without a stack frame in Unknown on line 0 has started showing up at the bottom of every page. I understand what the error means: an exception is getting thrown someplace it can't be thrown. I've even managed to track it down somewhat—it's happening during the time shutdown functions are being called.
I've put logging in all the functions which get registered with register_shutdown_function, and it's not happening in any of those. Unfortunately, I can't seem to get any more information than that; I know what the last shutdown function to get called successfully is, but I have no idea what code gets executed between that and the point where the error happens. I don't even know what part of the PHP machinery is calling that last shutdown function. It might be something with the logging framework, or the session framework, or anything of a half-dozen things.
Does anyone know how to pinpoint where the error is occurring?
This can happen in destructors and exception handlers which don't have a stack frame. But since the message is so very helpful, your only option is to try to use echo to find the bug (and maybe ob_end_flush()). It may be that a destructor is throwing an exception, or is calling a function that throws an exception. Once you've located the buggy function, add a try...catch around the exception throwing part.
Note that if your framework uses its own error handling, you have to turn off warnings and notices in the PHP configuration. Especially if you have something like ErrorException, since it turns warnings into exceptions.
This message appears when an exception in thrown within your exception handler or your error handler (and maybe also in shutdown functions)
You should look for theses methods see if nothing strange appens in here.
Just found your question after experiencing the same error in a web application deployed to a Ubuntu 11.04 server, running PHP 5.3.5. I agree to #Eisberg that this issue seems to be an issue with the PHP 5.3-version exclusively, as the error haven't been present with previous, other PHP versions on other environments, where my application have been deployed to.
As #jmz mentions, I have also utilized an error handler that turns errors into exceptions for easier debugging at my staging servers.
To figure out what caused this mysterious behaviour, I debugged the application using XDEBUG & my IDE (Eclipse) and found out that one of my libraries tried to access & modify the global$_SESSION variable, when no session-data were set. Wrapping my code in an if-statement checking isset($_SESSION) made the issue disappear.
Why the exception didn't bubble up completely all the way to the browser, as other errors have done when trying to access non-set variables, is a complete mystery for me, especially as I got below error settings set, but maybe altering the setting in error_reporting() would have made a difference.
Error handling settings, for reference:
error_reporting(E_ALL | E_STRICT);
ini_set("display_errors", 1);
ini_set("html_errors", 1);
I get the same error msg too. MySQL database quota was set by awardspace as 50mb. Using PHPmyAdmin to optimise files showed a size of 34 mb but at cPanel the size was shown as 57mb. Every time when I visit my website and this error msg occurred, all I need to do was to login into awardspace, choose database, management, and reset file permissions. Then the error msg goes away, and my website is back up.
I was getting this issue in PHPUnit. I have added below code in function tearDown and helps me to get the actual error. You should wrap destructor inside a try-catch block, as the stack-frame only gets lost as soon as the exception is getting outside the destructor. Might be this can help someone else too. Source
function __destruct()
{
try
{
/*
your code
*/
}
catch(Exception $e)
{
echo $e->__toString();
}
}
I have a script in production - an ecommerce checkout page - that has had some errors in the past that have prevented it from working and have cost me money. I wanted to get notified on errors so I worked this up:
<?php
function mailErrorHandler($errno, $errstr)
{
echo "<!--PHP ERROR:";
echo "---[$errno] $errstr ---";
echo "-->";
error_log("Error: [$errno] $errstr",1,
"myemail#myserver.com","From: me#workserver.com");
}
set_error_handler("mailErrorHandler",E_ALL);
echo 1-thisisnotanumber;
?>
When I use it as-is in it's own script, it works and executes quickly. However, when I add it to my existing application, the page load time decreases DRAMATICALLY i.e. 40 seconds as opposed to <1 second. Can anyone think of a reason why this might be happening?
If you have a significant amount of traffic and you're throwing a LOT of errors, writing to the log can cause a significant amount of disk IO. This can slow down your app to the extent that you're talking about.
Maybe what you're throwing isn't errors, but rather a bunch of Notice "exceptions". If you have them set to not display (the default in most versions of PHP) and you're getting a boat load of them, you could be running your error handler hundreds and hundreds of times. Every time the handler is run, it has to do a trace, break out of the current scope, do all sorts of processing, and if that's all happening because you're using =& new with PHP 5.3 or trying to access undefined array elements (or any other common notice), you're going to see those kinds of delays.
So in order to fix this, the doctor prescribes turning off the error handler on your test server, turning on the display of notices, run through the flow and take note of any errors/notices/etc, then fix the aforementioned notices on your production box.
Hope this helps!
Hmm. When you say "use it on it's own", do you mean in a separate page that is invoked through Apache, or are you running it on the command line? The delay, combined with the use of email makes me suspect a DNS or network issue...something not resolving or not connecting and timing out.
Another thought...fire up Xdebug and do a profile dump while this is running and see if that sheds any light on what is taking all the time.
Try to add an exit() after the error_log() call.
An other solution would be to log to a file if you have problems with the error_hander:
Set
log_errors = On
html_errors = Off
error_log = log
in your php.ini, then all the errors will be logged into the default error.log of your server.