Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:29621 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 92333 invoked by uid 1010); 21 May 2007 14:52:36 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 92318 invoked from network); 21 May 2007 14:52:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 May 2007 14:52:36 -0000 Authentication-Results: pb1.pair.com smtp.mail=stas@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=stas@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 63.205.162.114 unknown Windows 2000 SP4, XP SP1 Received: from [63.205.162.114] ([63.205.162.114:34821] helo=us-ex1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EB/89-03101-132B1564 for ; Mon, 21 May 2007 10:52:35 -0400 Received: from [127.0.0.1] ([192.168.17.30]) by us-ex1.zend.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 May 2007 07:52:30 -0700 Message-ID: <4651B227.4080103@zend.com> Date: Mon, 21 May 2007 07:52:23 -0700 Organization: Zend Technologies User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Nuno Lopes CC: Stefan Esser , PHP internals References: <465022BE.1020905@hardened-php.net> <4651351D.8010306@zend.com> <46513D1C.2030104@hardened-php.net> <00d101c79bb5$ef107ed0$0100a8c0@pc07653> In-Reply-To: <00d101c79bb5$ef107ed0$0100a8c0@pc07653> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 May 2007 14:52:31.0014 (UTC) FILETIME=[A8694460:01C79BB7] Subject: Re: [PHP-DEV] Dismantling the lies... From: stas@zend.com (Stanislav Malyshev) > For the record the patch I had is this: > http://mega.ist.utl.pt/~ncpl/zend_stack_protection.txt (it shouldn't > apply cleanly due to some changes in zend_try some time ago). Ah, this is different think - it's more like a nice error message, not preventing stack depletion. > Knowing in advance if you can recurse or not doesn't sound much > difficult in theory.. You can get the limit (e.g. with getrlimit) then > you can know how much stack does a function call take, and then you can PHP function calls are not the only things that take stack space. > use a heuristic to make the decision. This isn't 100% secure though (the > limited depth approach isn't too), but it's an option. I would love to > ear how other VMs handle the problem, like the JVM, anyone? Probably they use recursion less (which may be done for Zend engine too, but that would require some work). Perl in same situation just runs out of memory. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/