Page MenuHomePhabricator

ResourceLoader: Invalid argument supplied for foreach
Closed, DeclinedPublicPRODUCTION ERROR

Description

Warning: Invalid argument supplied for foreach() in /usr/local/apache/common-local/php-1.21wmf9/includes/resourceloader/ResourceLoaderWikiModule.php on line 225

Details

Reference
bz44907

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:21 AM
bzimport set Reference to bz44907.
bzimport added a subscriber: Unknown Object (MLST).
  • class ResourceLoaderWikiModule
  • protected function getTitleMtimes
		if ( !$batch->isEmpty() ) {
			$res = $dbr->select( 'page',
				array( 'page_namespace', 'page_title', 'page_touched' ),
				$batch->constructSet( 'page', $dbr ),
				__METHOD__
			);
			foreach ( $res as $row ) {

Database::select

  • @return ResultWrapper. If the query returned no rows, a ResultWrapper
  • with no rows in it will be returned. If there was a query error, a
  • DBQueryError exception will be thrown, except if the "ignore errors"
  • option was set, in which case false will be returned.

Someone leaks the ignore error option here?

So I did a quick grep on the core, and $db->ignoreErrors() is not called anywhere. The function is literally unused. The only reason I can think of for this error occurring is if DBO_IGNORE is set in the flags for starting the database connection.

On that note, is it really sane to be returning false from $dbr->select()? If the ignore errors flag was set, it means the caller doesn't give a damn about errors whatsoever. I feel like the correct behavior would be to return some sort of empty fake result wrapper.

Removing target milestone that was in the past.

If you want this in a specific release, have a good reason AND you are willing to find resources to fix this bug, feel free to change it to something appropriate.

Krinkle added a project: Technical-Debt.
Krinkle set Security to None.
Krinkle removed a subscriber: Unknown Object (MLST).

Does this still occur? Filed over two years ago…

Krinkle claimed this task.

No matches in the last 7 days.

While the code still has no check for a false return value, the code is specifically selecting a value that's expected to exist. So arguably it shouldn't need to check it. Presumably whatever bug caused data to sometimes not exist has been fixed.

mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:12 PM