I have developed a script that uses php's imap_search and when it gets to the stage of finding the emails with the function imap_search() i get a error being produced
php in free(): error: chunk is already
free
Abort trap: 6 (core dumped)
This script requires to be run through a cron, But when it does it does that above error and seems to abort the script, If i run from the browser it has this error inside the error logs but still runs the script in full.
Below is the line it is failing on:
$this->mailbox_emails = imap_search($this->mailbox_stream,'ALL');
This is an internal php error. File a bug on the imap module (if you want it fixed fast, include an SSCCE).
Also note that this is a memory corruption issue, which is usually caused (long) before it is noticed. Therefore, the imap_search function is probably not the buggy one; the imap_* function you used just before it is a good candidate.
Related
I can not find any answer to this as most problems revolve around a file not existing or a delete process not working.
I have an FTP device where I generate a file with an PHP script. After that, I try to FTP in, get the file and after that, delete it.
This all works fine, I can connect, get the file and save it locally and then delete it. Except for one thing, the ftp_delete() function results in a warning.
PHP gives me the following, when executing the script:
A PHP Error was encountered
Severity: Warning
Message: ftp_delete(): Command okay
I looked up the error code, it means it was successful. And it was because the file is deleted on the FTP device.
So why does this generate an PHP error?
Cheers.
The RFC 959 (FTP specification) mandates that on a successful completion of the DELE command, the server should respond with 250 status code.
The PHP FTP implementation is very strict, yielding a warning on any other code, even if it indicates a success (2xx class).
Your server probably uses some other 2xx code, like a generic 200 Command okay.
I am getting the below error while triggering the file with crone jobs, while it doesn't show any error with manual triggering. Please help whats the logic behind this error. Thanks
Fatal error: Call to a member function find() on a non-object in /home/afghannewscom/public_html/auto/MainProject.php on line 35
Look at the file MainProject.php on line 35 (in editor) and see whats the problem.
the variable $OuterLink is not an object. you may have a look at its definition line.
I also had a similar issue with cronjobs (PHP errors in cronjobs only, running file via browser was fine). The error was caused by incorrect server configuration (it was a shared server, so I couldn't change it). In my case, the fix was pretty easy - I changed cronjob from "php -q /some_file.php" to "curl http://somedomain.com/some_file.php" (you can also use lynx or wget command instead of curl)
Every now and then an image resizing script on our site will fail with the following error:
PHP Fatal error: Class '\xa0L\xdaor\x7f' not found ... on line 4
The actual line 4 of the script in question is:
$photo = new Photo($photo_id);
I have no idea where the hex code \xa0L\xdaor\x7f in the Error log comes from. The script will run fine and it runs relatively frequently for a day or two, then it starts failing every time, with that error.
If I run opcache_reset(), the errors stop.
Anyone have any idea what might be causing this issue?
UPDATE: I got no response - so I've simply excluded this file from the opcode cache using opcache.blacklist_filename.
Sometimes my whole PHP response was a bunch of hex codes like this.
I had that when opcache.fast_shutdown="1" was set.
On PHP 5.3.3-7, I'm using DOMDocument->load() to load a local file, and recently I've started encountering situations where I start getting E_WARNINGs
DOMDocument::load() [domdocument.load]: I/O warning : failed to load external entity "/path/to/local/file/that/does/exist"
Once this starts happening the only way I've found to make the errors stop is to restart apache, and then it's fine for a while again.
I haven't changed any related code recently, but it occurred to me that this started happening after I installed a Debian patch for CVE-2013-1643, which seems to possibly disable entity loading... if there's a single instance of an event that would trigger disabling, could that disable it permanently for all future PHP requests until a restart? That seems aggressive. By contrast, libxml_disable_entity_loader() seems to operate on the current request only.
I have no code that I know of that should ever load remote XML and that would ever trigger disabling, but if this is what's happening, I would have expected something to show up in my php error log, but I don't see anything. What other avenues should I investigate?
EDIT: Finally, I've been able to predictably repeat the problem. If I intentionally exceed the allowed memory limit in a single session...
mod_fcgid: stderr: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes)
...then I start getting the I/O warning on all subsequent calls to DOMDocument->load(). This time, I was able to get it working again without restarting apache... just by calling libxml_disable_entity_loader(false). This is truly funky behavior--it's starting to smell like a bug in php?
I'm experiencing a strange situation.
My application logs lot of trace logs to a file. (I don't know exactly how, I use my frameworks logger. Can check this though)
Problems is, when an application is terminated by a fatal error (only fatal) [example - "Fatal error: Call to a member function someFunction() on a non-object"] , I end up with no logs, even logs that should have been recorded much earlier during the execution of my script.
(Yes, I tried to flush logs, this doesn't help either. It looks like the termination of the application by a fatal error, somehow cancels writing to files done at earlier points of the application.
Any ideas what goes on here?
Thank you
A Fatal Error is... well... Fatal : it stops the execution of the script, which will not do anything that should have been done.
In your case, I suppose your logging framework logs into memory -- and that this in-memory log is only written to the file when the processing of the request is done.
Some logging mecanisms do that, to avoid writing to a file several times, at different points during the generation of the response (which means keeping the file locked, to avoid concurrency problems ; or opening-closing-reopening-reclosing-... it)
As you get a Fatal Error, the normal operation that should be done at the end of the response's generation is not called -- and, so, the in-memory log is not written to the file.
Now, the only way to know for sure would be to take a look at the logging mecanisms of your Framework ;-)
Apparently, the fatality of the fatal error that Pascal mentioned, is not 100% fatal.
The below allowed me to have my logs even on fatal errors:
function correctShutdown()
{
logger->flush();
}
register_shutdown_function('correctShutdown');