WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 7 weeks ago

#21870 accepted defect (bug)

@ error control operator hides fatal error on mysql_fetch_object

Reported by: ericlewis Owned by: pento
Milestone: 4.2 Priority: normal
Severity: normal Version: 1.5
Component: Database Keywords: needs-refresh
Focuses: Cc:

Description

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.

Attachments (3)

21870.diff (1.1 KB) - added by nacin 2 years ago.
21870.2.diff (1.3 KB) - added by ericlewis 2 years ago.
As per the previous talk, forking open the discussed can of worms and removing the error control operator from mysql_query.
21870.patch (1.8 KB) - added by tyxla 7 weeks ago.
Refreshing the latest patch to be compatible with the current code version.

Download all attachments as: .zip

Change History (20)

comment:2 @scribu2 years ago

  • Keywords needs-patch added; 2nd-opinion removed

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.

comment:3 @nacin2 years ago

#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].

@nacin2 years ago

comment:4 follow-up: @nacin2 years ago

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.

comment:5 @nacin2 years ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Awaiting Review to 3.5

comment:6 in reply to: ↑ 4 ; follow-up: @ericlewis2 years ago

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.

comment:7 in reply to: ↑ 6 @ericlewis2 years ago

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.

comment:8 follow-up: @nacin2 years ago

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.

comment:9 in reply to: ↑ 8 @ericlewis2 years ago

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.

@ericlewis2 years ago

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

comment:10 @nacin2 years ago

  • Keywords 3.6-early added
  • Milestone changed from 3.5 to Future Release

comment:11 follow-up: @rmccue11 months ago

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

comment:12 in reply to: ↑ 11 @pento11 months ago

  • Keywords needs-refresh added; has-patch 3.6-early removed

Replying to rmccue:

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

Thanks for volunteering! ;-)

comment:13 @ericlewis4 months ago

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.

comment:14 @wonderboymusic2 months ago

  • Milestone changed from Future Release to 4.2

@tyxla7 weeks ago

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

comment:15 @ericlewis7 weeks ago

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.

comment:16 @nacin7 weeks ago

  • Owner set to pento
  • Status changed from new to assigned

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.

comment:17 @pento7 weeks ago

  • Status changed from assigned to accepted

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

Note: See TracTickets for help on using tickets.