Re: [Phpwiki-talk] current CVS InlineParser

[Reini U. <ru...@x-...>]

I found now the problem with the current InlineParser, why it fails only 
on sf.net:
The problem is that the php at sf.net has less memory for regular 
expressions than a typical php, both have an 8M memory_limit, but 
somehow anchored pcre regex obviously allocate from somewhere else.

The problem is RegexpSet::_match with the huge regexp string, which now 
with the added Inline plugin markup overflow its limit.

The pattern is contructed from
   $pat= "/ ( . $repeat ) ( (" . join(')|(', $regexps) . ") ) /Asx";
The modifier A (ANCHORED) tells pcre to store the block, regexps is an 
array of 10 rather complicated regex strings, and repeat starts from 
"*?" to {nn} towards the end, so that the prematch gets longer and 
longer, until nothing is found anymore and the final "$" regexps 
matches. This ends the loop.

On sf.net we don't have an endless loop, we rather run out of memory, 
because of the continued anchored matching of the same huge regexp, 
until repeat gets large enough. The /A tells pcre to store the matching 
block to notify match() which regexps actually matched, and to be able 
to recurse into shorter substrings then.

I rewrote now that critical part to be somewhat slower, but to need much 
less memory.
We don't really need to string-join the regexps array together.
It is sufficient to loop through all regexps until one balanced or 
simple markup matches.
The problem is that the longest substring should be favoured, so that it 
recurses into matches, that's what /A is for.
e.g. for "<small>*WikiWord*</small>" it has to match at first the 
balanced <small> tag, than the *...* emphasis and at last the wikiword 
inside.

The hugest partial regexp is the interwiki map which constructs 
"(moniker1:|moniker2:|moniker3:|moniker4:|moniker5:|moniker6:|moniker7:|...)"

Without this regexp it doesn't run out of memory anymore.

Joby Walker schrieb:
> I haven't been able to reproduce the error.  Which is too bad because I 
> have just finished setting up Xdebug.
> 
> Reini Urban wrote:
>> Dan Frankowski schrieb:
>>
>>> I was not able to reproduce the problem. I might work on debugging 
>>> the SourceForge site if I had access to it. What's the word on that?
>>
>> The problem is for us developers, that we can only do printf-style 
>> debugging on sf.net, and this only for one day. On the next night the 
>> whole content will be overwritten by steve's automatic cvs update script.
>>
>> But most importantly we cannot use a php debugger there.
>> So I would love to see anyone with debugging skills, on whose site 
>> this problem also exists. This would narrow the search for the 
>> possible problem.
>>
>> Yesterday I could reproduce a similar problem with an endless loop in 
>> the InlineParser, and so at least some parts of the website are 
>> accessible again.
>> I also found a strange dba session problem with this special php 
>> version 4.1.2 and 4.1.1, but not really related to my current problem.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/