At my workplace, we are running a Magento 1.3 storefront, and we are having a problem with a job that is being run by Magento's internal cron service. Troubleshooting is nearly at a halt because we can't identify which job is causing the problem. The only feedback that we're getting is that every night at 00:05, cron coughs up the following, notoriously unhelpful PHP error while executing /usr/bin/php-cgi -f /path/to/app/magento/html/cron.php.
PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 50 bytes) in /chroot/magento/html/lib/Zend/Db/Statement/Pdo.php on line 294
Increasing PHP's memory limit is clearly not the answer - at 512mb, the problem is almost certainly that an algorithm is doing something grievously wrong, not that we've underestimated the requirements of the problem. Our database is fairly modest in size - a plaintext dump of the entire thing is less than 512mb, so a query would have to be pretty pathological to eat more than that. Our best guess is that something is probably using Zend's fetchAll() incorrectly, but that method isn't being called directly in anything we can find.
How can we get Magento to give us a stack trace or some other indication of its internal state at the time of the problem? Is there a way to get more transparency into exactly what PHP is trying to execute when it hits the memory wall?
Ideally, we would like to do this without modifying third-party code - sometimes plugin developers use bullfeathers measures like Zend Guard, or have a license that does not permit us to modify their broken code, or other measures that basically make me want to go find Mr. Stallman and give him a warm, grateful hug.
Please note that the problem is not "how do we solve the out-of-memory error?" That's been asked many times before, and answered with varying excellence. The problem is "how can we tell which PHP file is causing the out-of-memory error?" It's a question about Magento internals, not about PHP qua PHP.
