Regexp in Preg_Match Function Returning Browser Error

preg_replace causing browser error

Split the string on newlines, and get the last line:

$lines = explode("\n", $str);
$last_line = array_pop($lines);

PHP preg_match stops responding at certain number of characters in string

Yes, there is the backtrack-limit

You can configure this in your php.ini file.

To be honest, a quick google search would have solved your problem...

PHP regex not working - returns NULL on local server, but works properly on other

You say you solved the problem, but if your solution was to increase the backtrack_limit setting, that's not a solution. In fact, you're probably setting yourself up for bigger problems later on. You need to find out why it's doing so much backtracking.

After \{\s?joomla-tag\s+ locates the beginning of the tag, the first .* initially gobbles up the remainder of the document. Then it starts backing off, trying to let the rest of the regex match. When it reaches a point where <+ can match, the .+ again consumes the rest of the document, and another wave of backtracking begins. And with yet another .* after that, you're making it do a ridiculous amount of unnecessary work.

This is the reason for the rule of thumb,

Don't use the dot metacharacter (especially .* or .+) if you can use something more specific. If you do use the dot, don't use it in single-line or DOTALL mode (i.e., the /s modifier or its inline, (?s) form).

In this case, you know the match should end at the next closing brace (}), so don't let it match any braces before that:

\{\s?joomla-tag\s+([^}]*)\}

Validation of a text with regex in PHP crashing apache

Apache is crashing due to a segmentation fault and stack overflow within the PCRE library due to PHP setting pcre.recursion_limit too large. See my answer to a related question: RegExp in preg_match function returning browser error for a more in-depth discussion of this problem.

Your regex has the form: (a)+ which when applied to a large subject string, will cause the segmentation fault crash. However, for this specific case the capture group is unnecessary and can simply be removed like so:

public function alpha_special($str)
{
    return ( ! preg_match("/^[-a-zA-Z0-9_-ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõöùúûüýøþÿÐdŒ!?¿¡()\".',:@\n\r ]{0,350}+$/i", $str)) ? FALSE : TRUE;
}

This change should fix your immediate problem.

preg_match_all( ) behaves differently on different servers

Is known the fact that PCRE has sometimes a few problems with text larger than 200 lines. Developers from Drupal and GeSHi were hit by this problem in the past.

References:

1. Drupal PCRE Issue @ March 23, 2012
2. GeSHi PCRE Issue @ February 02, 2012

Maybe if you can split the text into small chunks (100 lines for example) and run regex on each chunk, may help.

preg_match and long strings

You'll be glad I found this question. As of PHP 5.2, they introduced a limit on the size of text that the PCRE functions can be used on, which defaults to 100k. That's not so bad. The bad part is that it silently fails if greater than that.

The solution? Up the limit. The initialization parameter is pcre.backtrack_limit.

PHP preg_match_all 100 MB file

Base on your code I suggest you to do it this way:

1. Set variable $data to empty string

2. Set variable $work to empty string; read block of data and append this string to $data

3. Use regex #^(.*?)(<tr>\n(?!.*<tr>\n).*)$# to split $data to $work and $data

4. Find all matches in $work

5. Go back to point #2 while data available

6. Find all matches in $data

---

Related Topics