Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113221 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 75289 invoked from network); 23 Feb 2021 15:06:03 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Feb 2021 15:06:03 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DA2651804C3 for ; Tue, 23 Feb 2021 06:54:33 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 23 Feb 2021 06:54:33 -0800 (PST) Received: by mail-lf1-f48.google.com with SMTP id v30so11611393lfq.6 for ; Tue, 23 Feb 2021 06:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=PlIPcsRW9C7zjXZra5m+0cbySPjhlU4ZRPCPHg2aoEQ=; b=iOdDT8o40htYykE8eE6qda4kMfmZxofTPvBVrTHd2L9whoVg05N7B1uZFwkdHDjp6p ogSBf6wmzjAetskgIAR6mm+aXnwlRpzNqx6Xh+1s3/fFej50jUbX0Rj7+hyBNFm1xqLx 13UnMIS03a2KVLpE9rSgoHnzj4bz6fvCLfVOsm8FxPRGs/mex5I8YjZ6syv8sh3TlH4d 8HsQg7+5+6AmXzzVIZorBcNZsagql3FdN4Pwvv8A2ASllYgUq4ud9XF3shixFwQbBaSG 4B7+0cfS3cshnTaNoI4QCYsj3/WUTpg5jpP+ElmNIo2JAEb45/g1agecp0poVmLHHWEU LeOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=PlIPcsRW9C7zjXZra5m+0cbySPjhlU4ZRPCPHg2aoEQ=; b=gu8xvjZcwlcU13VVhVwCFtJU+1IahOPMIMmK3mwt7jLFBNsWA6fidku38d/hRY7AFL RGkaN6fKbOS3/cIF2d2gD6nRkusvuZH13TUuD/NHaK1zvV0XS6o3qh5C1+rnP2KtXERc lmNs5/Lwry2Ozx3I8ZwU6McSPZd75S0YmO9icTIsMLaRJ2WXS1LqSeFsXdtUrNgFM1pC sf0VD2N3APQneoPqDz94US6YdSKn+bygXxyx63OB2eY2xY2gF3YqwT2WFZ1d1Jmfaz6+ 1/Rdtd62ipzeQmQlQvLl8v3q2xwUNBev6YkNsplP2apiuAOMCIQCjV9fjvl0jeDt3oI+ Nu/Q== X-Gm-Message-State: AOAM5336exOXBQCT+pJ/WAQ8cADDasorL3tQRAu9TUCmUdlDYdQ1MIbz qMVIQMqj8umrIzh8n3piHpR1QsxA5ac7T8s/fltBIVaLygk= X-Google-Smtp-Source: ABdhPJyIV20plDVpaoa2exwUiF28Jlv2z5aewqX0CD09w4p+qonoy76OhAnuroHzCM0GD2nnVCF/jvzCGirdlH1J6yU= X-Received: by 2002:ac2:4c32:: with SMTP id u18mr10871541lfq.223.1614092070719; Tue, 23 Feb 2021 06:54:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 23 Feb 2021 15:54:14 +0100 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="00000000000082941405bc021854" Subject: Re: VM reentry limit From: nikita.ppv@gmail.com (Nikita Popov) --00000000000082941405bc021854 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 3, 2020 at 2:29 PM Nikita Popov wrote: > Hi internals, > > We have a long-standing issue (tracked at > https://bugs.php.net/bug.php?id=64196 and the very numerous duplicates) > that certain types of infinite recursion can lead to a stack overflow. > While for us it is easy to diagnose this, end users will only see a > "segmentation fault" and will be unable to correlate this with infinite > recursion as the root cause. > > To provide some technical context, recursion in PHP usually occurs on the > virtual machine stack, in which case unbounded recursion is supported, as > long as the stack size does not exceed your memory limit. However, some > types of calls (in particular magic methods and certain callbacks) go > through an internal function and have to reenter the virtual machine. This > uses up space on the C stack and may ultimately result in a stack overflow. > > I would like to propose the introduction of a zend.vm_reentry_limit ini > option as a solution to this problem, implemented in > https://github.com/php/php-src/pull/5135. This ini setting will limit the > number of nested VM reentries that are allowed before an Error is thrown. > > It should be noted that this is (intentionally) not a general recursion > limit. Deep recursion can happen legitimately (e.g. during AST processing) > and it is hard to put a reasonable upper limit on it that both detects > unintentional infinite recursion while allowing legitimate deep recursion. > The limit implemented here exists specifically to prevent stack overflows > and give the programmer a more obvious indication of the cause of the > problem. > Bump. One open question here is how the error should be reported, when the VM reentry limit is hit. What my current implementation does is to throw an Error exception, which is nice in that it contains a stack trace. As this error condition is caused by infinite recursion, having a stack trace available is fairly valuable. On the other hand, using an Error exception can also cause issues, because they can be caught, and they go through normal unwinding. For example, a destructor run during unwinding could cause the limit to be hit again, which would probably lead to some non-obvious behavior. Regards, Nikita --00000000000082941405bc021854--