Description: ------------ Revision 1.7 of Text/Wiki/Parse/Default/Code.php breaks this page: http://wiki.horde.org/TurbaOutlook2003. Reverting to 1.6 fixes the rendering.

I hit the same problem and discovered the problem arises if you have more than 999 chars inside <code></code> (as in your situation). This code fragment shows the problem: <?php // This is actual regex - revision 1.7 $regex = ';^<code(\s[^>]*)?>((?:(?R)|.*?)*)\n</code>(\s|$);msi'; $text = '<code>' . str_repeat('x', 1000) . "\n</code>"; $result = preg_replace($regex, 'It worked', $text); var_dump($result); ?> Expected result: string(9) "It worked" Actual result: NULL Setting 999 in str_repeat(), the program works properly. I suspect this regex hits some limit... In the uploaded patch, I use another regex approach, trying to use a cleaner solution (in my opinion) but still accepting nested <code> tags. Also works if put on the same line, resolving bug #12098.

Running a modified version of Nicola's code: <?php $regex = ';^<code(\s[^>]*)?>((?:(?R)|.*?)*)\n</code>(\s|$);msi'; for ($i = 900;; $i += 100) { $text = '<code>' . str_repeat('x', $i) . "\n</code>"; $result = preg_replace($regex, 'It worked', $text); print "$i: "; var_dump($result); }?> on PHP 5.2.6 gives me the result: 900: string(9) "It worked" 1000: string(9) "It worked" 1100: string(9) "It worked" 1200: string(9) "It worked" 1300: string(9) "It worked" 1400: string(9) "It worked" 1500: string(9) "It worked" 1600: string(9) "It worked" 1700: string(9) "It worked" 1800: string(9) "It worked" 1900: string(9) "It worked" 2000: string(9) "It worked" 2100: string(9) "It worked" 2200: string(9) "It worked" 2300: string(9) "It worked" 2400: string(9) "It worked" 2500: string(9) "It worked" 2600: string(9) "It worked" 2700: string(9) "It worked" 2800: string(9) "It worked" 2900: string(9) "It worked" 3000: string(9) "It worked" Segmentation fault on PHP 5.2.5, exactly same machine: 900: string(9) "It worked" 1000: string(9) "It worked" 1100: string(9) "It worked" 1200: string(9) "It worked" 1300: string(9) "It worked" 1400: string(9) "It worked" 1500: string(9) "It worked" 1600: string(9) "It worked" Segmentation fault So it seems that its something up to the PHP version you are running.

I did one more test with PHP 4.4.8 and it failed at 1000 chars.

Sounds like pcre.backtrack_limit that has been introduced with PHP 5.2.0 with a too small default value.

Am inclined to wontfix this without a testcase, due to 'there is something wrong with your php' comments (if there's a test case I'm missing it) :S

There is a test case: http://wiki.horde.org/TurbaOutlook2003 Grab the source and pass it through the default Text_Wiki parser/renderer.

Have had this problem for years. Large < code > snippets crashed, just blank white page, no php errors or anything. Thought it might have been the php.ini pcre.backtrack/recursion limits but no. Thanks for the patch, all I did was replace the $regex in Parser/Default/code.php with this one var $regex = ';<code(\s[^>]*)?>\n?((?:[^<]*(?R)?.*?)*?)</code>;msi'; Now I can have virtually unlimited < code >, thanks.

@Jan: Do you mind writing a small script to reproduce this. I don't know what all you refer to when you say 'get the source and use the default renderer'. It would really help, since then I could try the latest suggested regex. Till

Test case committed and patch applied. Thanks for this. [We'll tackle the test suite issues later.]

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.