Make WordPress Core

Opened 7 years ago

Closed 4 years ago

#37283 closed defect (bug) (wontfix)

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

Reported by: thebfg's profile thebfg Owned by: pento's profile pento
Milestone: Priority: normal
Severity: major Version:
Component: Database Keywords:
Focuses: Cc:


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.

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

Attachments (1)

mysqli_LOCK_crash_POC.php (546 bytes) - added by thebfg 7 years ago.
proof of concept file

Download all attachments as: .zip

Change History (5)

7 years ago

proof of concept file

#2 @dd32
7 years ago

  • Keywords 2nd-opinion close added

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.

#3 @dd32
6 years ago

  • Component changed from General to Database
  • Owner set to pento
  • Status changed from new to reviewing

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

#4 @pento
4 years ago

  • Keywords 2nd-opinion close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reviewing to closed

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.

Note: See TracTickets for help on using tickets.