PDOException loses its message when querying with invalid UTF-8 due to check_plain()

Created on 28 February 2013, over 11 years ago
Updated 28 August 2024, about 2 months ago

I am dealing with a module (CMIS) that is trying to insert content into the database with the wrong charset. I was getting the following two errors:

    Warning: htmlspecialchars(): Invalid multibyte sequence in argument in check_plain() (line 1545 of /var/www/drupal/includes/bootstrap.inc).
    PDOException: in field_sql_storage_field_storage_write() (line 448 of /var/www/drupal/modules/field/modules/field_sql_storage/field_sql_storage.module).

However, the exception handling code in errors.inc combined with check_plain() means that the error message is completely lost in the PDOException. Note that the exception above has no message or trace.

That is, in includes/errors.inc#_drupal_decode_exception(), if $exception->args() contains invalid characters such as from file content, the displayed exception in the logs is simply:

PDOException: in field_sql_storage_field_storage_write()

If I remove print_r($exception->args, TRUE) from the $message, then the exception becomes (infinitely more useful):

PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect string value: '\xD0\xCF\x11\xE0\xA1\xB1...' for column 'body_value' at row 1: INSERT INTO {field_data_body} (entity_type, entity_id, revision_id, bundle, delta, language, body_value, body_summary, body_format) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8); in field_sql_storage_field_storage_write() (line 448 of C:\hubnet\drupal\modules\field\modules\field_sql_storage\field_sql_storage.module).

This is definitely due to the if ($exception instanceof PDOException) block, because if I remove it, the exception becomes (still useful):

PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect string value: '\xD0\xCF\x11\xE0\xA1\xB1...' for column 'body_value' at row 1 in PDOStatement->execute() (line 2139 of C:\hubnet\drupal\includes\database\database.inc).

I'm not sure what the best solution is, since in most cases you'd want to keep the arguments. Is there a way to check that a given string is valid w.r.t. a given charset before passing it to check_plain() - perhaps with drupal_validate_utf8()?

This seems to almost be a duplicate of "Error messages not generated in UTF8 in some situations" - but this is occurring on two different platforms (Linux, Windows) with MySQL.

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
BaseΒ  β†’

Last updated 36 minutes ago

Created by

πŸ‡³πŸ‡ΏNew Zealand soundasleep

Live updates comments and jobs are added and updated live.
  • Needs manual testing

    The change/bugfix cannot be fully demonstrated by automated testing, and thus requires manual testing in a variety of environments.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

  • Needs screenshots

    The change alters the user interface, so before and after screenshots should be added to document the UI change. Make sure to capture the relevant region only. Use a tool such as Aviary on Windows or Skitch on Mac OS X.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request β†’ as a guide.

    In addition to the manual testing this will need a test case to show the issue.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Believe this change now qualifies for the new policy of being small enough to not warrant tests. but definitely needs an issue summary update.

  • First commit to issue fork.
Production build 0.71.5 2024