[gravitypdf-bot]

Draft: the fix and its test are in. The changelog entry and the pre-merge gates are still to come.

The bug

$mpdf->WriteHTML("<p>\xE2"), HTML ending in a cut-off UTF-8 sequence, never returns.

On invalid input, purify_utf8() loops and asks iconv where the bad byte is. iconv returns false and reports either "illegal character" or "incomplete multibyte character". Only the first message is checked. On the second, strlen(false) makes $pos 0, substr($html, 0) changes nothing, and the loop repeats, logging an empty entry each time. A logger that keeps its entries runs out of memory instead of hanging.

Reading the message through error_get_last() causes a second hang: an error handler that returns true keeps the notice out of it, so "illegal" goes unseen too.

Inputs that hung

Measured on PHP 7.4, 8.2, 8.3 and 8.5 with libiconv on macOS, with the same results on all four:

• Default error handling: a 2, 3 or 4-byte sequence cut off at the end of the string, after at least one ASCII byte, including after a leading BOM. Also a lone lead byte above \xF4, such as <p>\xF5.
• An error handler that returns true: the above, plus almost every other invalid input with an ASCII byte or \x80 at the start, such as <p>\xE2 ok</p> or \x80.

A string made up only of a cut-off sequence, such as \xE2, did not hang, because the loop stepped over the leading high bytes.

The fix

The loop is gone, and iconv with it. purify_utf8() finds the first bad byte by comparing the input with its mbstring round trip, logs it and throws. Nothing repeats, so there is nothing left to hang.

$start was never read, and on the versions probed the loop body ran at most a couple of times with a useful result.

Public messages

• Everything invalid now throws Invalid input characters. Did you set $mpdf->in_charset properly?, the message most invalid input already got.
• HTML contains invalid UTF-8 character(s). See log for further details is removed. It was thrown for inputs such as \xE2, \xF4\x90\x80\x80 and a five-byte sequence, which now get the message above.
• Valid UTF-8 starting with a BOM is wrongly rejected on PHP 8.2+ today. It moves to the other message until Draw an inline object that follows a U+FEFF that leaves no text #871 lets it through.
• The [[#226]] log entry is now written for all invalid input, where before it was written only on the second message's path. It also now counts \x80 as a bad byte, which > 128 skipped.

purify_utf8_text() and ignore_invalid_utf8 do not use this loop and are unchanged.

Test

PurifyUtf8Test runs each case in its own process through Fixtures/purify-utf8.php, with set_time_limit(5), so a regression fails instead of stalling CI. The limit counts CPU time on Linux and wall-clock time on Windows.

Against the unfixed code all 18 tests failed in about 11 seconds, the truncated cases by exhausting memory in the recording logger. With the fix they pass on PHP 8.5.

Overlap with #871

#871 replaces the round trip in is_utf8() with mb_check_encoding() and rewrites this loop's condition. The conflict is on the while line: keep this PR's version with no loop, and #871's is_utf8(). The round trip here still finds the offset after that.

Not yet done

• Changelog entry
• Simplify and deslop pass
• Full composer test, composer cs and PHPStan
• New test on PHP 7.4, 8.2 and 8.3

PHP 5.6 cannot be run locally and is left to CI.