/* LOCK */ in SQL query crashes mysqli with no error message and prevents automatic updates

[thebfg]

Three queries containing the comment /* LOCK */ in the query text were introduced in the following three files:

wp-includes/revision.php in changeset 23849
wp-includes/taxonomy.php in changeset 33615
and the most problematic:
wp-admin/includes/class-wp-upgrader.php line 772 in changeset 36349
(Not linking to changeset as this Trac crashes when linking).

The problem lines typically look like this:

$lock_result = $wpdb->query( $wpdb->prepare( "INSERT IGNORE INTO `$wpdb->options` ( `option_name`, `option_value`, `autoload` ) VALUES (%s, %s, 'no') /* LOCK */", $lock_option, time() ) );

When Using MariaDB on Debian Jessie (not tested with mysql, the Debian version should not play a role), the call to mysqli_query fails with no error, no log message, and no other trace in the database, php, or system logs. The php script execution stops at that point. Since this type of query is now used in the updater, the update process stops (both from the WP Interface and from wp-cli)

Minimum example code illustrating this bug is attached. Note that the word LOCK itself plays no role; anything between /* and */ will cause the crash. Inputting the same query from the mysql/mariadb console is not problematic.

I have solved this by removing the /* LOCK */ part from the query, but I am not certain this is the right way as I do not know why it was put there. According to both MySQL and MariaDB comment syntaxes, it should be a non-executable comment, i.e. it doesn't change the query meaning.

Versions:
MariaDB (mysqld Ver 10.0.25-MariaDB-0+deb8u1 for debian-linux-gnu on x86_64 ((Debian)))
Debian Jessie (Linux 3.16.0-042stab111.12 #1 SMP Thu Sep 17 11:38:20 MSK 2015 x86_64 GNU/Linux)
php5-mysql: Installed: 5.6.22+dfsg-0+deb8u1

[thebfg]

proof of concept file

[thebfg]

Direct links to the affected lines:

https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-upgrader.php?annotate=blame&rev=37837#L843

https://core.trac.wordpress.org/browser/trunk/src/wp-includes/revision.php?annotate=blame&rev=37837#L627

https://core.trac.wordpress.org/browser/trunk/src/wp-includes/taxonomy.php?annotate=blame&rev=37837#L3802

[dd32]

Hi @thebfg and welcome to Trac!

I do believe these are the only locations we use comments in SQL, which are there to provide hints to database dropins and the like as to what the query is.

I don't think removing these is the correct action here, it sounds like you have hit a bug in PHP or one of the custom things compiled into PHP which is causing a segfault on your system, It could even be a php security module, which is probably very specific to your distribution, and most likely not a core PHP bug.

I'd focus efforts on determining why PHP is dieing at that point rather than failing gracefully and getting that bug fixed/feature disabled.

[dd32]

@pento mind taking a look here and making a decision?

[pento]

Aye, this would be a bug in the database server, it should be ignoring those comments. Given that they're used elsewhere, this isn't something we can change to work around the server bug.