Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:28857 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74160 invoked by uid 1010); 16 Apr 2007 10:19:11 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 74144 invoked from network); 16 Apr 2007 10:19:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Apr 2007 10:19:11 -0000 Authentication-Results: pb1.pair.com smtp.mail=david.sklar@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=david.sklar@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.132.240 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: david.sklar@gmail.com X-Host-Fingerprint: 209.85.132.240 an-out-0708.google.com Received: from [209.85.132.240] ([209.85.132.240:60510] helo=an-out-0708.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B3/7B-18278-E9D43264 for ; Mon, 16 Apr 2007 06:19:11 -0400 Received: by an-out-0708.google.com with SMTP id c28so1942778ana for ; Mon, 16 Apr 2007 03:19:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=HftPB7ZgzKHsAhlQ3gKusDNx3x06b0APeU5fYWa2WZJFiAj0nSQ6/dUzDdRiGhlETs2eFn7AFnBc81pxIgWbvMnby5/fuhdKcviPblai9pIP3xF8/OrwMhGB0pKJn2yZ9EF0txlaVRt7+iCYi2C6zkazqaOjiL2Efr5iFRaPx/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Gtai18OQJw+j/Tbuq8vAf1ICENxiU9MItrCWKMyQ6uXjbwAddPrlz8XhkVtuWCRoQmXNVw3+OrL+yzQtnr9trcJp0PNmrtOpQ0Izht1ZHSFIosKqj6mrsZ7OZrIIBTuTFEpq8zcte3fSDK6ekYh05gAKHS84gpHfzDkbJ5+kTiU= Received: by 10.100.136.13 with SMTP id j13mr4342234and.1176718747186; Mon, 16 Apr 2007 03:19:07 -0700 (PDT) Received: by 10.100.168.17 with HTTP; Mon, 16 Apr 2007 03:19:07 -0700 (PDT) Message-ID: <7cea347c0704160319x619b26d0s7716e35493e122c4@mail.gmail.com> Date: Mon, 16 Apr 2007 12:19:07 +0200 To: internals@lists.php.net MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Trapping "memory exhausted" error From: david.sklar@gmail.com ("David Sklar") I am interested in being able to trap the (currently) fatal error that results when memory usage exceeds the defined memory limit. I was thinking it could work as follows: - in addition to a memory_limit configuration directive, there could be a "memory_limit_grace" configuration directive. This gets stored in the struct _zend_mm_heap, along with the limit. - Also added to struct _zend_mm_heap is a "initial limit reached" flag - When zend_mm_safe_error() in Zend/zend_alloc.c is invoked under the current conditions (memory_limit exceeded), it sets the "initial limit reached" flag, adjusts the heap limit to the "memory_limit_grace" value and throws some non-fatal error (or an exception if it is feasible from here.) - When zend_mm_safe_error() is invoked and the "initial limit reached" flag is already set, it throws the fatal error exactly as it does now. This "grace period" would provide a way to gracefully exit when a memory limit is reached, but also has the hard limit still enforced so that code which is supposed to be gracefully exiting doesn't chew up too much additional memory. Is it feasible to adjust the heap limit and throw a non-fatal error from within zend_mm_safe_error()? David