Shutdown function

Comments

5 comments

  • Andreas Huttenrauch

    Actually, it turns out that my shutdown is being called, but debug_backtrace is empty.
    This is weird as it only happens when memory is exhausted from inside the Podio library, not when I exceed memory in my own code.

    0
    Comment actions Permalink
  • Andreas Huttenrauch

    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.

    0
    Comment actions Permalink
  • [100Rails] Nathan Bromberg

    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.

    0
    Comment actions Permalink
  • Andreas Huttenrauch

    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 function

    I'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 log

    There'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.

    0
    Comment actions Permalink
  • [100Rails] Nathan Bromberg

    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.

    0
    Comment actions Permalink

Please sign in to leave a comment.

Powered by Zendesk