Description:
------------
Trying to capture more than 99998 bytes from one string captures
nothing. Same behavior happens also in other PCRE functions.

You can see more test results in the original place where was reported:
http://tracker.moodle.org/browse/MDL-11237

Reproduce code:
---------------
<?php

/// Change this if you want, but 99999 is the limit in my system (Darwin
mbp 8.10.1)
    $numchars = 99999;

/// Test begins here
    echo 'PHP: ' . phpversion() . '<br />';
    echo 'OS: ' . php_uname() . '<br />';
    $all = '';

    for($i=0; $i<$numchars-2; $i++) {
        $all .= 'x';
    }
    $all = '@' . $all . '@';
    preg_match_all('/@(.*?)@/is', $all, $results);
    if ($results[0]) {
        echo 'OK, preg_match_all() has been able to capture one text of
' . strlen($results[0][0]) . ' bytes.<br />';
    } else {
        echo 'ERROR, preg_match_all() has NOT been able to capture one
text of ' . strlen($all) . ' bytes.<br />';
    }

?>

Expected result:
----------------
It should show:

OK, preg_match_all() has been able to capture one text of 99999 bytes

Actual result:
--------------
ERROR, preg_match_all() has NOT been able to capture one text of 99999
bytes

UHm...

It seems that, since 5.2.0 it's necessary to adjust the
"pcre.backtrack_limit' setting to allow more chars to be returned (in
ungreedy matches). So, something like:

 ini_set('pcre.backtrack_limit', 20971520); /// 20 MB

will allow up to 20MB of text to be matched. 

Radical change (without notices?) from previous versions...uhm.

Ciao :-)

Expected behaviour. And it was a bug fix to prevent crashes / out of
memory issues. Not bug -> bogus.