As part of \core_search\document::set function, it does a preg_replace with the Unicode /u modifier.

On some systems (for example a server running RHEL 7 with PHP 5.6.31, PCRE library version 8.32) this function returns null if passed a source string containing the (non-)character U+FDD0.

On other systems (for example my desktop running Windows 7 with PHP 7.0.14, PCRE 8.38) it works fine.

We had a very few forum posts containing this character. I have fixed them in the database.

I don't propose taking any specific action involving this character - it seems like this character is not really a problem for search alone and if we were to block it, it should be done somewhere when accepting user input; also it's very rare. However, I suggest we improve the exception message to make it easier to track down this problem if it occurs to others in future.

Note: The following complete PHP script is sufficient to observe this issue. On systems with the problem it will output 'null' from the var_dump. On systems that don't it will output a string containing the character.

<?php

$str = '';

$evil = html_entity_decode($str);

var_dump(preg_replace('/x/u', '', $evil));

 Example of error message you get before this change:

Scheduled task failed: Global search indexing (core\task\search_index_task),Coding error detected, it must be fixed by a programmer: Missing "content" field in document with id "mod_label-activity-1145"

Example of error message you get after it:

Scheduled task failed: Global search indexing (core\task\search_index_task),An error occurred while indexing
Debug info:
"content" value causes preg_replace error (may be caused by unusual characters) in document with id "mod_label-activity-7"

Small change but it took me a long time to debug this because the unusual character wasn't visible to the naked eye so I didn't notice it; I had been assuming the content value was somehow blank.