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
Related
We have a SOAP service that receives files as byte content. This service works fine for small files, but is failing for files ~25MB or larger. In the case of large files, the SOAP call executes but returns null. It literally returns nothing--no error message, no message at all. My associate indicated that the server is generating a 500 internal server error, which somehow gets back to the client but disappears in my testing. Tracing the code indicates that the handle() method of the code is not throwing an eror but also not doing anything at all--not calling the service's authorization method nor the method that puts the file to the server.
What is the likely cause of this problem, and how can I resolve it?
I think the client that calls the soap stop the service before having the answer.
Try to increase the value of default_socket_timeout in your php.ini.
You can also increase the value of max_execution_time
I hope it will help you. :)
I'm posting because after hours of searching I'm utterly confounded. Here's the deal. My Laravel application uses the PHP Image Workshop bundle. Everything seems to be working fine, except if I try to make a resizeInPixel() call or a cropInPixel() call (or similar calls) the server throws an internal server error. If I investigate the error log I see:
Premature end of script headers: index.php
This only occurs when I use the resize and crop related methods (i.e. image processing). I can initFromPath() with no issue, and I can use the save() method without issue. Only the image processing methods cause the internal server error.
I've also read online that this can be the result of a suphp_log file exceeding 2GB. I've tracked down and cleaned out that file, but to no avail.
Any thoughts are most welcome! Even if they're just general "have you tried...".
UPDATE
I've narrowed it down to a particular line in the Image Workshop code. This line is causing the error:
imagefill($image, 0, 0, $color);
Additionally, this error only occurs when the color is created using imagecolorallocatealpha, NOT when it is created using only imagecolorallocate.
There are some great hints for solving this issue at Liquidweb.com. My money is on #2 (see bold text) because you are getting the error when doing image manipulations:
Sometimes when executing a script you will see an error similar to the following:
Premature end of script headers: /home/directory/public_html/index.php
This error occurs because the server is expecting a complete set of HTTP headers (one or more followed by a blank line), and it doesn’t get them. This can be caused by several things:
Upgrading or downgrading to a different version of PHP can leave residual options in the httpd.conf. Check the current version of PHP using php -v on the command line and search for any lines mentioning another version in the httpd.conf. If you find them, comment them out, distill the httpd.conf and restart apache.
The RLimitCPU and RLimitMEM directives in the httpd.conf may also be responsible for the error if a script was killed due to a resource limit.
A configuration problem in suEXEC, mod_perl, or another third party module can often interfere with the execution of scripts and cause the error. If these are the cause, additional information relating to specifics will be found in the apache error_log.
If suphp’s log reaches 2GB in size or larger you may see the premature end of scripts headers error. See what the log contains and either gzip it or null it. Restart apache and then deal with any issues that the suphp log brought to light. The suphp log is located at: /usr/local/apache/logs/suphp_log
The script’s permissions may also cause this error. CGI scripts can only access resources allowed for the User and Group specified in the httpd.conf. In this case, the error may simply be pointing out that an unauthorized user is attempting to access a script.
UPDATE:
After some more info in the comments, I still feel this is a memory related thing.
According to this SO wiki: About gdlib
Warning: Image functions are very memory intensive. Be sure to set memory_limit high enough
What is your PHP memory_limit? Can you crank it up a bit?
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.
Just installed a nginx server with ubuntu 11.04 and after loading my php program i was writing i noticed that no MYSQL queries run. I get no errores, either from PHP nor MYSQL.
The user my PDO connection uses has all priviledges.
When i change the host to any value, i do not get any error either.
I believe mysql is not showing any connection error. How do i check it's enabled? Just checked mysql.conf and i see nothing related to error reporting. Also looked php.ini and all error options are enabled, i also enabled it in-code.
I have no clue, it's useless to work with no kind of error reporting!
Thanks!
Where are your error logs for nginx? Have you looked in those? Is mysql running? Try service mysql status. PHP should still give you an error though if it can't connect to the database. How do you know the queries are not running? What I mean is, what are the symptoms? Maybe the queries are running but your input is bad?
Most important is to try to isolate the problem. 1) Use curl -v http://your_server to make sure nginx is actually serving the pages. 2) Set up a phpinfo.php file in the root web directory with <? phpinfo(); ?> and check the mysql settings and verify where log files for php are being written 3) Try installing phpmyadmin and see if you can connect to the database using that.
Each one of the above eliminates at least 1 of the elements (your program, PHP, nginx, mysql), helping you to narrow down the cause of your problem.
EDIT: Additional instructions for item 2. You are looking for the php error_log setting. If it is not set, the errors should go to stderr, which in this case I think would be your nginx log files (true at least for apache). You could also check that error_reporting is set to some reasonable value (try error_reporting=E_ALL for now). You can set both of these in your php.ini file, or in your program. See the manual in section PHP Error Handling Runtime Configuration. I would do a sanity check by triggering an error in my program at the beginning of the program and making sure the error shows up in the log file:
trigger_error('Want to be a rock star test message', E_USER_WARNING);
If you see your message, you've got the right log file and you should find your other errors (if any - mysql might not be the problem, could be bad input as I mentioned before).
I was wondering if anybody knew of a method to configure apache to fall back to returning a static HTML page, should it (Apache) be able to determine that PHP has died? This would provide the developer with a elegant solution to displaying an error page and not (worst case scenario) the source code of the PHP page that should have been executed.
Thanks.
The PHP source code is only displayed when apache is not configured correctly to handle php files. That is, when a proper handler has not been defined.
On errors, what is shown can be configured on php.ini, mainly the display_errors variable. That should be set to off and log_errors to on on a production environment.
If php actually dies, apache will return the appropriate HTTP status code (usually 500) with the page defined by the ErrorDocument directive. If it didn't die, but got stuck in a loop, there is not much you can do as far as I know.
You can specify a different page for different error codes.
I would assume that this typically results in a 500 error, and you can configure apaches 500 handler to show a static page:
ErrorDocument 500 /500error.html
You can also read about error handlers on apaches documentation site
The real problem is that PHP fatal errors don't cause Apache to return a 500 code. Errors except for E_FATAL and E_PARSE can be handled however you like using set_error_handler().
There are 2 ways to use PHP and Apache.
1. Install PHP as an Apache module: this way the PHP execution is a thread inside the apache process. So if PHP execution fails, then Apache process fails too. there is no fallback strategy.
2. Install PHP as a CGI script handler: this way Apache will start a new PHP process for each request. If the PHP execution fails, then Apache will know that, and there might be a way to handle the error.
regardless of the way you install PHP, when PHP execution fails you can handle errors in the php.ini file.