Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108348 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 48647 invoked from network); 3 Feb 2020 15:17:55 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Feb 2020 15:17:55 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5106018050F for ; Mon, 3 Feb 2020 05:29:49 -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=-2.1 required=5.0 tests=BAYES_00,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-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (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 ; Mon, 3 Feb 2020 05:29:48 -0800 (PST) Received: by mail-lf1-f42.google.com with SMTP id v201so9674441lfa.11 for ; Mon, 03 Feb 2020 05:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=bQzwE1nelzlYhOOJFIWfaJEUlMpqjOaqAcDyNNq1DJ4=; b=jw5oDba/GJYrzEafN1v98hx1zfLqEg7kK5ftVMHzOw0l7BoAB4gyIswZoD286kUI0y julQ2osrh0x80CvEYzqVrGKYaNRK6Ol9shbiuHLq8LuAmRMYNryV53WYxVp/a4gNugNZ F55P77yp0Fsr5j1s08dErwrIf5NN9grRPPNVhpJ+mkBIKtE6SAtFu1wUv/gdgRuSASk8 E1lvOqKnuGljalP9K9QXbB762B9b7LWJv59H/bBJDujES9cA3ef4VjbKEkgqikZ5Vozz eAlLK9WXzQMUCto/JHQBheLLWXuUue8o5DADJEp4oMkTZ/GxKp269/9LsaXa4UWl7ZZm kVFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bQzwE1nelzlYhOOJFIWfaJEUlMpqjOaqAcDyNNq1DJ4=; b=JBzKqffpmIxB24Y2lx/zjzH3kxjcvB3PzRzax+W5JZ6xUJBJpxc+GvWM8qst3/eDwE dpBmYL5JYUFSZYFtv6GrSe9LiSouLUBOW9jQ6jtn4bYDd8MDLvubG4JfoqYTXvlodhoW 9k4U9A/wUddSzEN+1Cx+RpR2dnMOaHMmxlnWQ+qeDEvCv4Fc7n7BmIUsi+dKWVAEuB6W S5heFggVw8Myey0jpzACV20vnNATLmt4rLsuTeacMKeAxl7xEkCrN4UMy6FdnlvqROH0 eVBpYEVyY8MMQdX3atwB83giIb+dIIsGojM6nGxOHS45Uiz+wuhZSaktHCU/T2v6wANj KhXg== X-Gm-Message-State: APjAAAVEoIEvhCNCd/2X78HotfH3ZpS4EU7Ci+uXbnC6U8d20XO3Kcqm 4AOaMwhBocY334Dzbbo6EKQbHqpaY2pna8XGhNXGN4GK6BI= X-Google-Smtp-Source: APXvYqwsWkRdIUPdDrCdsq+HSsdUJzn06nRmA4KY9BNe4YqschNT+tRp5yvWHbqu90qi1Mhs1k1W82yd3QpRAaB4+eM= X-Received: by 2002:ac2:43c6:: with SMTP id u6mr12074732lfl.191.1580736583590; Mon, 03 Feb 2020 05:29:43 -0800 (PST) MIME-Version: 1.0 Date: Mon, 3 Feb 2020 14:29:27 +0100 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="0000000000008c6815059dabea3d" Subject: VM reentry limit From: nikita.ppv@gmail.com (Nikita Popov) --0000000000008c6815059dabea3d Content-Type: text/plain; charset="UTF-8" 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. Regards, Nikita PS: Some extensions will force all function calls to occur via VM reentry. Such extensions should probably either disable the option (by setting it to -1), or significantly increase the limit, to avoid false positives. --0000000000008c6815059dabea3d--