Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74771
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.220.174 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH7nx2=kyA4O+B5-fMOAgrNjDNyBFiiWNPisk-ztZ6+PxQ@mail.gmail.com>
References: <BLU0-SMTP17590EBA81C73B80FBD2DC4E2F30@phx.gbl>
	<1361810738.2376.74.camel@guybrush>
	<BLU0-SMTP192F5092E7FAF349E58EF14E2F30@phx.gbl>
	<512BA931.7010909@sugarcrm.com>
	<BLU0-SMTP440413F63B6853F3921B28AE2F30@phx.gbl>
	<512BB284.4060900@sugarcrm.com>
	<BB36A9AE-15FE-48F4-BC6E-536DD6B9ECD7@hotmail.com>
	<BLU0-SMTP84AA375FFBF9F72D47CB87E2F30@phx.gbl>
	<1361826106.2376.78.camel@guybrush>
	<BLU0-SMTP17598AB345B5FB936E836B2E2F30@phx.gbl>
	<BLU0-SMTP592778DB54F0E3C384B3FEE2FD0@phx.gbl>
	<512E6732.6010601@sugarcrm.com>
	<CAH-PCH7BHyF9fenTR5Tqih_0=xY4O3_y2h3GmfPh4JGhgEXWtQ@mail.gmail.com>
	<CAH-PCH7nx2=kyA4O+B5-fMOAgrNjDNyBFiiWNPisk-ztZ6+PxQ@mail.gmail.com>
Date: Fri, 6 Jun 2014 10:55:59 +0400
Message-ID: <CA+9eiLvd4PTQtCQar3Hbt6i125v_HmFmXouB_d-m+xYKj-rUVg@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Dmitry Stogov <dmitry@php.net>, 
	Bob Weinand <bobwei9@hotmail.com>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01177721a3e0f504fb255a58
Subject: Re: [PHP-DEV] About restricting the recursive implicit calls
From: dmitry@zend.com (Dmitry Stogov)

--089e01177721a3e0f504fb255a58
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The overhead of the patch is negligible, so it's not a big problem to
include it from perf point of view, however:

1) It won't prevent crash because of C stack overflow, in case the limit is
too big.
2) Disable check with some default value (0 or -1)  would be also good
3) I'm not sure about naming. It would be better to use something more
clear in INI name and error message,

May be instead of this, we should check C stack pointer in
zend_call_function() and throw exception or error, when the pointer comes
close to the limit?
This check must be compiler and may be platform specific :(

Thanks. Dmitry.



On Fri, Jun 6, 2014 at 10:25 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

>
>
>
> On Wed, Feb 27, 2013 at 10:15 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
>>
>>
>>
>> On Wed, Feb 27, 2013 at 9:06 PM, Stas Malyshev <smalyshev@sugarcrm.com>
>> wrote:
>>
>>> Hi!
>>>
>>> > May someone merge this PR (#290) as there are no arguments against it=
?
>>>
>>> I just outlined arguments against it in my last emails. If your email i=
s
>>> not working properly and you miss some emails please check the list
>>> archives.
>>>
>>> > Or do I have to wait a little bit? (How long?)
>>>
>>> In my personal opinion, indefinitely long, since I think it is not a
>>> good idea at all to have it in the core, and the same functionality
>>> already exists in xdebug.
>>>
>>>
>> and in suhosin.
>> I think that it is a pretty handy feature, both from the security
>> pov(hitting a fatal error is better than php crashing, killing the worke=
rs,
>> resetting random seed, etc.) and can help with debugging the problem(as =
you
>> will lose the non flushed output buffer on the crash).
>> so if we could find an implementation which addresses your issues(no
>> major perf cost, sane defaults, no edge cases left out, etc.) then I can=
't
>> see why we shouldn't add it.
>>
>> --
>> Ferenc Kov=C3=A1cs
>> @Tyr43l - http://tyrael.hu
>>
>
> sorry for resurecting the old thread,
> if we are concerned about the perf cost of counting and checking the
> recursion, and that the default value would break some application, maybe
> we could introduce this as an optional feature: the ini setting is 0 by
> default, which will disable even the checks for recursion, so people have
> to opt-in to use it and it's their burden to configure it properly.
> I know that this would still allow distros and hosters to misuse it, and
> probably some apps will start checking for this setting to (hopefully onl=
y)
> warn about the setting being too low, or even picking a different strateg=
y
> when the setting is too low or simply increasing the limit at runtime.
> maybe we can do something in the next major version which would allow us
> to gracefully bail from these kind of errors without imposing arbitrary
> limits?
>
> --
> Ferenc Kov=C3=A1cs
> @Tyr43l - http://tyrael.hu
>

--089e01177721a3e0f504fb255a58--