Added by krileon about 12 years ago. Updated over 7 years ago.
Description
When you've content more then 300 characters contained in an IF substitute statement it seams to crash the server. This is confirmed using CB Content Bot in a Joomla article.
Files
| substitution_if_regexp.txt (162 Bytes) substitution_if_regexp.txt | krileon, 31 October 2016 19:06 |
Updated by krileon almost 12 years ago
The below can be used to confirm this issue anywhere substitutions are used.
[cb:if user_id="myid"]1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890[/cb:if]
Updated by krileon almost 12 years ago
Appears to be a stack overflow issue for preg_replace_callback. On windows servers it's quite small (like 1MB) while linux is significantly higher. Seams the only solution is to increase that stack overflow for apache or use smaller strings in their substitutions (maybe break it up into 3 or 4 of the same substitutions to keep them smaller). Don't see a solution we can implement without forcing the string into chunks, which could just end up breaking the substitutions if a substitution got split incorrectly.
Updated by beat almost 12 years ago
Updated by beat over 11 years ago
Not really an issue in CB imho. Something to keep in mind for CB 2.0.
Updated by krileon over 7 years ago
This is due to the massive amount of backtracking taking place. The current REGEXP will take 15,886 steps in the REGEXP engine to match a string with 7,953 characters. The proposes new REGEXP only takes 42 steps.
SEE ATTACHED FILE
The problem is the new usage can't work with IF substitutions that are side by side. This is simply early findings and of course needs further investigation, but this maybe fixable with just better REGEXP.
Updated by krileon over 7 years ago
This is easily fixed by limiting the backtracking by fixing the [^\[] to [^\[]+. This will group up strings that it can so they're checked in chunks instead of literally character by character. It will only backtrack if it needs to from the other conditions.
Updated by krileon over 7 years ago
Fixed in MR !1121