@ error control operator hides fatal error on mysql_fetch_object

[ericlewis]

I ran a get_posts() query that took me a while to track down to the @ error control operator on the mysql_fetch_object call (see wp-db.php:1219 in trunk), therefore PHP was silently die'ing on me because of a memory limit error.

I'm curious as to what use cases there are for the error control operator to be used here. In my case, I want to see these errors and fix my code accordingly, or tailor my query to the memory constraints, or rethink my data relations in the database.

[ericlewis]

Related: #9158

[scribu]

I assume error suppression is used because mysql_fetch_object() throws a notice when there is no object left to fetch.

Should be a way around that, though.

[nacin]

#11151 as a duplicate?

I don't see any notes in the documentation that mysql_fetch_object() can throw a notice. It returns false if there's nothing else to fetch. However, if the resource isn't a resource, you get a warning. We eliminated similar error suppression in [21511].

[nacin]

21870.diff​ avoids error suppression on mysql_fetch_object(), mysql_num_fields(), mysql_fetch_field().

mysql_query() should additionally be good, because $this->dbh is guaranteed to be a resource, I guess unless someone unset it (if the connection fails, we bail in db_connect()). But touching that seems more dangerous than these.

[ericlewis]

Not to veer to much in the direction of #9158, but what about the @ operator on the mysql_query call a bit earlier in the function?

$this->result = @mysql_query( $query, $this->dbh );

This seems related and perhaps ripe for removal as well, as any error raised by this call is probably developer error.

[ericlewis]

Replying to ericlewis:

Not to veer to much in the direction of #9158, but what about the @ operator on the mysql_query call a bit earlier in the function?

$this->result = @mysql_query( $query, $this->dbh );

This seems related and perhaps ripe for removal as well, as any error raised by this call is probably developer error.

Since we'll be taking care of support for PDO and the mysqli_* class in #21663, I'm gonna retract what I said about perhaps removing the error construct for mysql_query(), because that could open up a can of worms that really doesn't need to be opened at all.

Thumbs up on nacin's patch.

[nacin]

There are no plans for PDO or mysqli. Not saying it's never going to happen, but *certainly* not for 3.5. Opening the can of worms is fine. I talked about why I avoided mysql_query() above.

[ericlewis]

Replying to nacin:

Opening the can of worms is fine. I talked about why I avoided mysql_query() above.

Ah whoops, I thought you meant it was good to leave as is.

[ericlewis]

As per the previous talk, forking open the discussed can of worms and removing the error control operator from mysql_query.

[rmccue]

Woo, 3.6-early! :) 4.0-early anyone?

[pento]

Replying to rmccue:

Woo, 3.6-early! :) 4.0-early anyone?

Thanks for volunteering! ;-)

[ericlewis]

I ran into a similar problem with hyperdb today. My feeling is we should remove @ operators entirely, and rewrite anything that may produce a PHP notice properly.

[tyxla]

Refreshing the latest patch to be compatible with the current code version.

[ericlewis]

While we're at it, we should consider removing all 14 @mysql_* invocations.

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14.

[nacin]

There is a *lot* of history here. A few of us spelunked this years ago and did remove some. Let's leave this for pento to make any decisions and commits.

[pento]

Aye, some of these can go away, with appropriate sanity checks. Hopefully there won't be too much stuff that explodes when we do.

[DrewAPicture]

A bit too late to dive down this rabbit hole for 4.2. @pento: Feel free to re-milestone if you feel like it's worth rolling the dice during beta.

[pento]

This looks like fun. Let's refresh the patch and add the bits from comment #15, then see what happens.

[ericlewis]

attachment:21870.3.diff​ removes all @ operators, and adds a few sanity checks to pass unit tests.

[pento]

21870.3.diff​ looks like a good start to me. Lets commit it and see what explodes.

[ericlewis]

In 35860:

Don't suppress error messages in database function calls.

Fixes #21870.

[Otto42]

Just a note, in WordPress 4.5, this fix is now causing issues where hosts with PHP 5.5 and WP 4.5 are attempting to connect with mysqli, and the mysql_old_password error is not being ignored properly and output to the page.

​https://wordpress.org/support/topic/authentication-failure-on-upgrading-to-wp45?replies=3

Because of the early output, cookies cannot be set, rendering users unable to log into wp-admin for their sites.

The fallback to the mysql client still appears to work okay on these sites (sometimes), however errors from mysqli_real_connect should be caught and handled somewhat better, I think. The real fix, of course, is for the database servers not to be configured to use the old_password hash mechanism, but still, that's a valid warning message to attempt to suppress.

[Otto42]

Now that warnings are not being suppressed anymore, a new warning is showing up for some users:

​https://wordpress.org/support/topic/wp45-upgrade-mysql_connect-error

This one is:

Warning: mysql_connect(): Headers and client library minor version mismatch. Headers:xxx Library:xxx in .../wp-includes/wp-db.php on line 1515

It can be resolved by switching the installations to use the nd_mysql or mysqlnd (native driver) libraries instead of the normal mysql or mysqli ones. This eliminates the need for the mysql client libraries, and thus resolves the version mismatch between them.

Edit: An easier fix which has been working for people is to configure their host to use a newer PHP version, which generally is configured correctly unlike older versions.

[pento]

In 37292:

Database: Suppress connection error messages when WP_DEBUG isn't enabled.

This is a partial revert of [35860], which has been causing un-catchable warnings to be generated on some server configurations.

Fixes #36629 for trunk.
See #21870.

[pento]

In 37293:

Database: Suppress connection error messages when WP_DEBUG isn't enabled.

This is a partial revert of [35860], which has been causing un-catchable warnings to be generated on some server configurations.

Merge of [37292] to the 4.5 branch.

Fixes #36629.
See #21870.