http://us.php.net/manual/en/pcre.configuration.php
Could it be those 2 configurable limits causing the problems? We had some problems here a while back with hitting the backtrack limit which was causing weird behaviour, perhaps your running into the same issues. On Wed, Apr 22, 2009 at 9:28 AM, Guillaume Oriol <[email protected]> wrote: > > Hi Matthew, > > I missed something when tracking this bug: > if you look closely to the regexp, you'll see a question mark following ".*" > in parenthesis. > I guess this is an error as I don't understand its meaning. > > On my server: > <pre> > $a = str_repeat('a', 49997); > $a = preg_replace('/^\s*(.*?)\s*$/s', '$1', $a); > </pre> > would return the string but: > <pre> > $a = str_repeat('a', 49998); > $a = preg_replace('/^\s*(.*?)\s*$/s', '$1', $a); > would return NULL. > </pre> > If I remove the question mark, preg_replace operates properly, whatever size > the string is. > > > Guillaume Oriol wrote: >> >> Thank you Matthew for your answer but, according to PHP manual, the trim() >> function removes ALL whitespace characters from beginning/end of the >> string (and not only the first one). Furthermore, the trim() function >> removes not only space but also: >> * "\t" (ASCII 9 (0x09)) >> * "\n" (ASCII 10 (0x0A)) >> * "\r" (ASCII 13 (0x0D)) >> * "\0" (ASCII 0 (0x00)) >> * "\x0B" (ASCII 11 (0x0B)) >> >> I will post a message to php-internals regarding the issue on >> preg_replace. >> >> >> Matthew Weier O'Phinney-3 wrote: >>> >>> -- Guillaume Oriol <[email protected]> wrote >>> (on Monday, 20 April 2009, 09:13 AM -0700): >>>> Hi, I discovered an issue with the >>>> javascriptCaptureStart/javascriptCaptureEnd >>>> function pair. When the captured text exceeds a certain limit (about >>>> 50kB in my >>>> case), the function returns only a semi-colon. I have the following code >>>> in a >>>> view script: >>>> >>>> <?php $this->dojo()->javascriptCaptureStart(); ?> >>>> var data = <?php echo $this->data; ?>; >>>> ... >>>> <?php $this->dojo()->javascriptCaptureEnd(); ?> >>>> >>>> And, as the number of rows in my database table is growing, $this->data >>>> is >>>> getting bigger and bigger. Finally, over ~50KB, the PHP tag returns a >>>> semi-colon and nothing else (not even the "var data =" preceeding that >>>> tag). >>>> I was able to trace this issue back to the function addJavascript($js) >>>> in >>>> Zend_Dojo_View_Helper_Dojo_Container and more precisely to the >>>> preg_replace >>>> function: >>>> >>>> $js = preg_replace('/^\s*(.*?)\s*$/s', '$1', $js); >>>> >>>> I replaced it by: >>>> >>>> $js = trim($js); >>>> >>>> and everything was fine. Therefore, I have two questions: >>>> - is there a know limitation on preg_replace() >>>> - why did you use a preg_replace function to trim the string ? >>> >>> I'm not aware of any limitations on preg_replace(), but you might want >>> to either file a bug with php.net or ask on the php-internals mailing >>> list about it -- that seems like odd behavior. >>> >>> We chose to use preg_replace over trim() as it allows removing more than >>> one whitespace character from front and back, and will include newlines >>> when doing so. >>> >>> -- >>> Matthew Weier O'Phinney >>> Project Lead | [email protected] >>> Zend Framework | http://framework.zend.com/ >>> >>> >> >> > > > ----- > Guillaume ORIOL > Sofware architect > Technema > -- > View this message in context: > http://www.nabble.com/size-limit-raised-on-javascriptCaptureStart%28%29-tp23139812p23175439.html > Sent from the Zend Framework mailing list archive at Nabble.com. > > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
