Shutdown function
I have my own shutdown function to report additional info for debugging.
I'm using the previous PHP library and it is somehow overriding my shutdown function.
Sometimes when using commands like PodioItem::filter, I run out of memory in PodioObject.php. I need to know how,when,why,etc so I can modify my code.
I tried to modify the shutdown functions in Podio.php and PodioApi.php but these do not seem to be called when memory runs out in PodioObject.php.
I tried adding a custom shutdown function to PodioObject.php but this didn't get invoked either.
How can I catch memory errors in the PHP library?
Any help would be much appreciated.
Thanks,
-Andreas
-
Well, I figured out the issue and am sharing in case it helps someone else.
Everything stopped working in the shutdown function at:
$new[] = print_r($tmp, true);
where $tmp = debug_backtrace();
Why print_r would stop all execution is a mystery, and why it would only do this in errors triggered by the Podio PHP library is even more of a mystery. All other errors caught are fine - print_r returns a pretty array.
And I know there's nothing wrong with $tmp because adding it to the log with serialize works fine - just print_r fails. -
Hey Andreas! Have you had any further luck with this one? We are using an up-to-date Podio-PHP library using the default shutdown function, and have started to receive memory errors in our log files as well. I can also see that is is coming from PodioObject.php, but have no further information than that. We use the default 128MB memory allocation per script, and this seems like an awful amount of textual/object data.
-
Yeah - I found a few things to watch out for.
If you register a shutdown function, it will trigger, however, there are some caveats:
1) The call stack is gone at this time
2) You're out of memory at this time, so just about anything you do will kill your shutdown function
2) Also remember that you can't call your own functions from within a shutdown functionI'm currently still finding all the places this happens in. My work-around is:
1) For every major function, set a global variable so I can get more info on what happened
2) Start the shutdown function with an ini_set to increase available memory for the process
3) Dump all globals into the error logThere's a stack overflow solution that suggests registering a tick function to keep your own stack trace in a global, but this is a very bad idea because it adds a LOT of processing overhead and slows down everything to a crawl.
Most of my issues are coming from calls like filter, search, or loops that get items. Using a hard ceiling for number of items is not a solution because memory usage can vary greatly. Small apps with little changes don't use up much, but complex apps and apps with many revisions and comments use a lot of memory (all this crud is returned in the items array).
I haven't done this yet, but my current thinking is to add policing code to all functions that search, filter, or get many items, to continually check memory usage and stop when a certain threshold is reached (eg 80%). All functions that get raw files need to check the file size and available memory before getting this.
It's a real shame that you can't just catch and recover from memory issues in PHP.
-
Thanks for that detailed reply! I will look at implementing those in the coming weeks. Leigh told me that he was blowing out your script memory limit with his flows! It would actually be good to have Andreas (Podio) weigh in on this, because it may come down to him giving options for the kind of data that is returned. For example, revision history and various other config information (which seems to create deep nesting) could be made optional with a switch.
Please sign in to leave a comment.
Comments
5 comments