Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87275
Return-Path: <cmbecker69@gmx.de>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 11231 invoked from network); 24 Jul 2015 18:14:37 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 24 Jul 2015 18:14:37 -0000
Authentication-Results: pb1.pair.com smtp.mail=cmbecker69@gmx.de; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=cmbecker69@gmx.de; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
X-PHP-List-Original-Sender: cmbecker69@gmx.de
X-Host-Fingerprint: 212.227.17.22 mout.gmx.net  
Received: from [212.227.17.22] ([212.227.17.22:54382] helo=mout.gmx.net)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 1F/00-10459-A8082B55 for <internals@lists.php.net>; Fri, 24 Jul 2015 14:14:35 -0400
Received: from [192.168.0.100] ([95.89.139.132]) by mail.gmx.com (mrgmx102)
 with ESMTPSA (Nemesis) id 0MbaS9-1ZbkTS3Hfh-00Iywf for
 <internals@lists.php.net>; Fri, 24 Jul 2015 20:14:31 +0200
Message-ID: <55B28090.8040405@gmx.de>
Date: Fri, 24 Jul 2015 20:14:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <55B0CADD.8000807@gmx.de>
In-Reply-To: <55B0CADD.8000807@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Provags-ID:  V03:K0:hDbwUH+KwpGzjwByQcjuo5RWqxG0ZEHPKdAQida7X8brFxnyktg
 d0z2lRa3D4RWRAJEMlKCHy40w3mgn+H3Gdg6nI8JzL4eUuT5AGHh4/NlxFLGi1vdQzRLNkU
 lr2QXv67QBXrlxFCLUYAcCNYBTEWfjPe2VkBkcxInqld25Fc2Rn+Ud0kugbvrF8oaorl6Ot
 PicMcCx4NnsVgpA/oxIXA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:zbHxVgr/R1I=:2g8teOQT5UqhLjA/yzY4Bt
 y48e9KydIjXDDWpoZLKFb1w0g19QFh52mV/zKu4xKtgCoVelQgKiePiReB4PfSvm1/aWIx/Wg
 79pf5eRCqTs5u2Y6Ug9hq/ijXlNjFMBH4jeBaPXRR2H4laSLh7e8ipJzBASAW5uOWR0RdTDmc
 1Cr6XvxzfdhPEtPr4PGQ9M4/KzK8a1Bajzn3N6hLETWGp9mD6pKFXUwfQFETXL/al9zV7vdd+
 HfRkXDEdlNHdzufcTGx89yXXdyyoY93FpBirkhMnOZudwEO7uT4xxFT6WPm5gjYMgDR4pA4Z0
 BTfY//S/9sCl6emWTkD6wDcygG1hkDBduWRX1Tlma7IX88J4cZ4iga7uxYYimV5H583F/NntU
 N0hM6BjTwBuUBaJV5gCVIFSprmuMTi2Mwib5G1Lz+z0DjOISQmJjHWoJXZg2JyuZdiUXUVjAs
 JTzeDudk05pAXf2wlI4egrpPphLlqcx3JzfEcSjX9HlC/qEy4RXkQ6zZ19IH0nfyOzockzyou
 PD6evVhNuPZqUn9W9ogGaAojxDjyZifFO+ZWdkYGV3jQIlczKZmzNzugXeuKeRzYxDPA6d32q
 xhol24C9UuurnE8kYy9/BP098vECoLOI2/erYMidi0T35Ibi2T72vkaRDNCEO3bBymLAi+5uK
 fEL2ceDUiX5N+y0k8MPz5l2bdEqoOMrypKdNGpNAI8PlORFO3M266OgKDP3lCNuvlw6g=
Subject: Re: PCRE JIT stack size limit
From: cmbecker69@gmx.de (Christoph Becker)

On 23.07.2015 at 13:07, Christoph Becker wrote:

> PHP7 supports PCRE's JIT compilation of patterns by default, which
> mostly works fine.  However, there are issues when the matching exceeds
> the JIT stack limit, see bug #70110[1].
> 
> I'm not sure how to solve this best.  Basically, I see two possible
> solutions: either we fall back to non JIT matching, if pcre_exec() fails
> with PCRE_ERROR_JIT_STACKLIMIT, or we use a custom JIT stack and make
> its size a configurable ini setting (similar to pcre.backtrack_limit),
> and raise E_WARNING if the matching fails due to limited stack size.
> 
> Thoughts?
> 
> [1] <https://bugs.php.net/bug.php?id=70110>

Zoltán Herczeg just told me that the size of the JIT stack doesn't have
to be fixed, but rather allows to dynamically grow up to a maximum given
size (preallocated by mmap/VirtualAlloc).  I'll do some testing and
report back later.

-- 
Christoph M. Becker