This took me a while to understand, but it seems that there's a limit in PHP aside from execution time and memory settings that is easily surpassed when preg_replace_callback() is used. Because this module uses that function, and because it's used on fields like a node body that have quite long inputs, I wonder if there shouldn't be some kind of warning in the readme or perhaps even on the status report page about this.
The setting is pcre.backtrack_limit
From PHP.NET's documentation page:
pcre.backtrack_limit defaults to 100k. This is rather conservative.
It is limited by RAM size, not the ulimit on stack-size.
And from PHP.net's preg_replace_callback() documentation page:
preg_replace_callback returns NULL when pcre.backtrack_limit is reached; this sometimes occurs faster then you might expect. No error is raised either; so don't forget to check for NULL yourself
The result is that long text entered into a custom filtered field will result in empty fields on output, even though on editing, the field looks good. There's a quick fix in settings.php, all you have to do is uncomment and configure the ini_set() call on pcre.backtrack_limit around line 315:
/**
* If you encounter a situation where users post a large amount of text, and
* the result is stripped out upon viewing but can still be edited, Drupal's
* output filter may not have sufficient memory to process it. If you
* experience this issue, you may wish to uncomment the following two lines
* and increase the limits of these variables. For more information, see
* http://php.net/manual/en/pcre.configuration.php.
*/
# ini_set('pcre.backtrack_limit', 200000);
# ini_set('pcre.recursion_limit', 200000);
Active
2.0
Documentation