Upgrading a very small site from 6.2 to 7.0, just looking for advice. When attempting to run update it starts and then dies here:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://www.fourtiresandfuel.com/update.php?id=18&op=do StatusText: Service unavailable (with message) ResponseText: Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /home/hoslot5/public_html/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1262 of /home/hoslot5/public_html/includes/database/select.inc).

Error page:
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).

The update process was aborted prematurely while running update #7012 in user.module. All errors have been logged.

If this is posted somewhere and I missed it I apologize, I need sleep :)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

plach’s picture

Category: support » bug
Priority: Normal » Major
Status: Active » Closed (duplicate)
Starminder’s picture

Status: Closed (duplicate) » Needs work

I don't see how this is even close to being a duplicate of that. This did not occur in a windows environment, and was related to update #7012 aborting.

This same site is still dead in the water this many months later. Using 7.7 core, the now 135 pending updates still aborts, the error message is now:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: (siteURL)/update.php?id=19&op=do StatusText: Service unavailable (with message) ResponseText: Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /home/hoslot5/public_html/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1261 of /home/hoslot5/public_html/includes/database/select.inc).

plach’s picture

You're right, sorry, I misread the OP. FWIW #1234834: 'module' column of role_permission table is not populated on upgrades fixes the issue I crossposted in #1.

Starminder’s picture

Aren't 7006 and 7012 different? I'd like to leave this open until the fix in #1234834 is committed and i can check it if that's ok. Thanks, glad to see this getting some attention, this site has been dead since upgrading.

rfay’s picture

Status: Needs work » Active

I just got this on an update from D5 through D6 to D7. It's a tremendously simple businesscard-type site. Seemed find when it got to D6.

CCK was not installed in either the D5 or D6 instances.

The reported error is

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://helminvest.l/update.php?id=3&op=do StatusText: Service unavailable (with message) ResponseText: Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /home/rfay/workspace/helminvest/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1261 of /home/rfay/workspace/helminvest/includes/database/select.inc).
rfay’s picture

rfay’s picture

Status: Active » Needs review
FileSize
608 bytes

Call is from user_update_7006():

$permissions = user_permission_get_modules();

It's caused by taxonomy_vocabulary_load_multiple().

I note that taxonomy was not enabled on the site being upgraded.

So what happened was that DrupalDefaultEntityController::buildQuery() does this:

    $entity_fields = $this->entityInfo['schema_fields_sql']['base table'] ;

but base_table is NULL (because taxonomy was not enabled, I assume)

then we hit

    $query->fields('base', $entity_fields);

which causes the fatal.

The attached patch lets the upgrade run to completion

rfay’s picture

Version: 7.0 » 8.x-dev
Issue tags: +Needs backport to D7

Same patch applies fine to D8. I guess we'll have to get it in there first.

rfay’s picture

Issue tags: +D7 upgrade path

Tagging upgrade path

plach’s picture

@rfay: did you try the patch cited in #3? it fixes exactly user_update_7006()...

rfay’s picture

@plach -- no I didn't try it. You pointed to it as being a mistaken attribution, to an issue that had nothing to do with this. And I don't see where #1234834-15: 'module' column of role_permission table is not populated on upgrades addresses the problem in this patch.

plach’s picture

I was asking because the issue I originally marked as duplicate of this one appears to be in a possibly similar situation: it has been marked duplicate of #1234834: 'module' column of role_permission table is not populated on upgrades even though it concerns a different issue, at least for what I can understand of it.

I am just curious to know if the patch over there removes the symptom also here.

catch’s picture

Status: Needs review » Postponed (maintainer needs more info)

Please try #1234834: 'module' column of role_permission table is not populated on upgrades, user_permission_get_modules(); should not be run anywhere during the upgrade path under any circumstances, nor should any other function invoking hooks. So if that's triggering the bug here then removing it from user_update_7006() is the right fix for this issue as well.

rfay’s picture

Status: Postponed (maintainer needs more info) » Needs review

I don't disagree, @catch, but think that #7 solves a (very simple) real core problem here, and should not be dismissed. These are not mutually exclusive fixes.

Setting back to CNR not to be confrontational, but because I think it should be fixed.

catch’s picture

If taxonomy_vocabulary_load_multiple() is being called when taxonomy module isn't even enabled, that's not fixed by having entity_get_info() work around it, we should instead figure out why taxonomy_vocabulary_load_multiple is getting called at all.

If taxonomy module isn't upgraded when this function is called, then that's the reason for removing the call from user_update_7006().

Is there a different bug here that this fixes?

rfay’s picture

@catch, #1234834-16: 'module' column of role_permission table is not populated on upgrades also allows the update to continue to completion successfully and resolves the OP here. Either approach would have fixed it. Both should be implemented, IMO.

catch’s picture

Why should entity_get_info() have special workaround code for missing base tables for a condition that can only exist during update though?

rfay’s picture

@catch, yes, the bug is that the existing code assumes an array in $this->entityInfo['schema_fields_sql']['base table'] and that's an invalid assumption.

catch’s picture

It's only an invalid assumption during upgrade though, because hooks cannot be reliably executed, which is why we have #1134088: Properly document update-api functions and a broken upgrade path for two years. module_implements() should ideally throw an exception during update so it is impossible to even reach this code. Are there any other circumstances under which you believe this could be triggered?

rfay’s picture

Status: Needs review » Closed (duplicate)

I really don't know this stuff anything like you do, so if you think it's impossible, we'll call this a dup.

Marking a dup of #1234834: 'module' column of role_permission table is not populated on upgrades

Starminder’s picture

Status: Closed (duplicate) » Active

For what it is worth, I ran update on this site - there are 135 pending updates. It fails here:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://www.fourtiresandfuel.com/update.php?id=20&op=do StatusText: Internal Server Error ResponseText: Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /home/hoslot5/public_html/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1261 of /home/hoslot5/public_html/includes/database/select.inc).

catch’s picture

Status: Active » Closed (duplicate)

@rfay it should be impossible, if there's another way to get to it, something else very bad is happening (which is not at all impossible given the sort of bugs in D7 at the moment).

@Starminder if you're getting that running updates it's likely the same thing. If you can dump a debug_backtrace() in there to see what comes through that'd help to confirm though.

Moving back to duplicate for now.

rfay’s picture

Status: Closed (duplicate) » Active

Umm... @Starminder you didn't mention what patch you applied, if any...

xjm’s picture

Status: Active » Closed (duplicate)

Fixing crosspost.

Starminder’s picture

Status: Closed (duplicate) » Active

sigh. I know we want to close this stuff, but I don't think you should be closing it until someone the community tests it, or at least cite what this is a duplicate of, which I think the answer is that it isn't.

xjm’s picture

#25: It was marked as a duplicate of #1234834: 'module' column of role_permission table is not populated on upgrades in #20. rfay and catch both have set it to this status. See catch's post in #22. If you can provide information as he suggests that indicates it is not a duplicate, then post that.

chx’s picture

Status: Active » Closed (duplicate)

ahem

asciikewl’s picture

Version: 8.x-dev » 7.8
Priority: Major » Normal
Status: Closed (duplicate) » Active

Sorry to open this again, but I'm running into this with a migration on D7.8 where the changes from http://drupal.org/node/1234834 has already been applied.

During development and migration I applied the patch in http://drupal.org/node/1158114#comment-4863562 to the dev tree and the error went away.

Now we are moving the dev database to a staging site where the paths etc are different. Placing the working D7 database in the new position, we then need to rebuild the paths to fit the new location.

Step 1: rebuilding registry works fine
Step 2: Rebuilding module,theme and css data fails when we do:
drush php-eval "system_rebuild_module_data();system_rebuild_theme_data();drupal_clear_css_cache();"

Clearing the caches also fails with the same error.

If I then apply the patch above, everything works fine. When I revert the patch, everything keeps working fine, so it could be a tricky one to re-create.

rfay’s picture

If you used Registry Rebuild to build the cache, it does a full cache clear... So I'm surprised you even see the need to do step 2 in #28.

DamienMcKenna’s picture

Running into this with D7.8 with a custom installation profile that contains a large number of contrib modules, a few custom modules and several features.

migrad’s picture

Status: Active » Needs review
mgifford’s picture

This patch hadn't gotten into 7.10 and this is still an outstanding issue. I applied this issue to core and all works properly now.

xjm’s picture

Version: 7.8 » 8.x-dev

Hmm, what about the patch in #1234834: 'module' column of role_permission table is not populated on upgrades? As far as I can tell from the comments above, that's the preferred way to fix this? Though that issue looks to be in limbo as well.

kevinquillen’s picture

I ran into this issue when building custom entities and while everything was fine and dandy for a few days, this error started happening. After applying rfay's patch in #7, this went away immediately.

xjm’s picture

@Kevin Quillen-- what about the patch in the other issue? Could you test that one as well?

kevinquillen’s picture

To reproduce (in my case) with D7.10, Entity API 7.x-1.0-rc1:

- Enable Entity API
- Create an Entity, with its own EntityUIController
- YourEntityUIController calls overviewTable(), which calls entity_load: $entities = entity_load($this->entityType, FALSE, $conditions);

The result is this error:

"Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /sandbox/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1320 of /sandbox/includes/database/select.inc)."

It would appear that $this->entityInfo['schema_fields_sql']['base table'] is not populated.

After applying rfay's patch, the error goes away, but then I get a new warning:

"Warning: Invalid argument supplied for foreach() in EntityAPIController->load() (line 223 of /sandbox/sites/all/modules/entity/includes/entity.controller.inc)." - which is in Entity API and not core entity.inc.

What is odd is I had created this particular Entity and its UI and CRUD a week ago and it worked perfectly fine, in the midst of many drush rr and drush cc all while working. Today is the first time I have seen this error, though nothing has changed in my entity code.

xjm’s picture

Alright, so it sounds like it is only reproduced sporadically, per #36? If we could find a specific set of steps to reproduce from "Install D7 HEAD" that would be really helpful.

@mgifford @DamienMcKenna @asciikewl -- Was the Entity API module installed when you saw the bug as well? If so, we might want to move this issue to that queue for a closer look.

lowkee’s picture

I got this issue while doing a clear cache all in order to install a few custom panels layouts using 7.10

The patch from rfay worked perfectly. The connection to panels may be simply timing, not causal.

I am using Entity API module.

Error:

Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1320 of includes/database/select.inc).

xjm’s picture

Project: Drupal core » Entity API
Version: 8.x-dev » 7.x-1.x-dev
Component: user.module » Entity CRUD admin UI
Status: Needs review » Active

Alright, moving to the Entity API queue for a closer look based on #38.

xjm’s picture

Component: Entity CRUD admin UI » Entity CRUD controller
tim.plunkett’s picture

Easy way to reproduce this: enable both http://drupal.org/sandbox/amateescu/1429904 and http://drupal.org/project/webform_entity, then clear the cache.

fago’s picture

It would appear that $this->entityInfo['schema_fields_sql']['base table'] is not populated.

The entity api module controller does nothing different with those fields than the core controller. The problem is that this is not populated, probably due to cache initializing issue.

I remember, the uuid module did or does some trickery here. Else, try to find the module or modules combination causing it...

Easy way to reproduce this: enable both http://drupal.org/sandbox/amateescu/1429904 and http://drupal.org/project/webform_entity, then clear the cache.

Yep, I think the webform_entity module should bypass entity_load in hook_entity_info_alter(). Using entity_load() at this stage could be the cause.

ShaneOnABike’s picture

I also encountered this when I enabled Rules module

madeby’s picture

Just got this error on a live D7.12 site after emptying the cache.

It broke the entire site and it was down for 2 hours before I applied the patch on this page.

Is the patch the way to permanently fix this or?

Damien Tournoud’s picture

Damien Tournoud’s picture

Project: Entity API » Drupal core
Version: 7.x-1.x-dev » 8.x-dev
Component: Entity CRUD controller » entity system

This is a core issue, as it is a case of info hook dependencies going haywire.

ShaneOnABike’s picture

But this is happening in D7 as well so shouldn't it be set to that version?

tim.plunkett’s picture

@ShaneOnABike, bugs are fixed in the latest branch first and then backported: http://drupal.org/node/767608

madeby’s picture

Just got this error as well with the entity module in core.

Notice: Undefined index: revision in entity_extract_ids() (line 7496 of /includes/common.inc).
Notice: Undefined index: load hook in DrupalDefaultEntityController->attachLoad() (line 334 of /includes/entity.inc).
Notice: Undefined index: load hook in DrupalDefaultEntityController->attachLoad() (line 334 of /includes/entity.inc).
Notice: Undefined index: load hook in DrupalDefaultEntityController->attachLoad() (line 334 of /includes/entity.inc).

Running D7.12.

srlawr’s picture

I have implemented the patch in #7, and though it has got me away from the WSOD with this error message, I now get a half-page-loaded, drupal error message:

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AS , revision.uid AS revision_uid FROM node base INNER JOIN node_revision revis' at line 1: SELECT base.*, revision.*, revision.timestamp AS revision_timestamp, base. AS , revision.uid AS revision_uid FROM {node} base INNER JOIN {node_revision} revision ON revision.vid = base.vid WHERE (base.nid IN (:db_condition_placeholder_0, :db_condition_placeholder_1)) ; Array ( [:db_condition_placeholder_0] => 37242 [:db_condition_placeholder_1] => 37244 ) in DrupalDefaultEntityController->load() (line 196 of \includes\entity.inc).

tim.plunkett’s picture

FileSize
541 bytes

Here's a very hacky patch I've been running in the short term.

srlawr’s picture

Yes, I have been "implementing" a similar mechanism, of simply adding the "true" in as a second parameter OD when it crashes out, but this provides a slightly more elegant way of maintaining that.

The fix in 17 of this issue http://drupal.org/node/1438278 does seem to have worked for me more long term though (well, 24 hours).. if it's worth checking out.

tim.plunkett’s picture

Indeed, #1438278-17: Latest dev crashes Drupal completely solves my problem and mitigates the need for my patch in #51.

Taras Zavaliy’s picture

Thanks to #7 patch my site (Drupal 7.16) works again! The problem however was not caused by update. After a lot of testing i still can't figure out this.

helmo’s picture

#7 also saved a site I'm working on (7.18).

As this site does not include the entityreference module, the solution from #53 was not applicable.

Elijah Lynn’s picture

Drupal 7.23 - Trying to run a Simpletest* threw this error. Applied patch in #7 and tests are running fine now.

* Tried three different Simpletests, 2 were custom & one was core -> 'Actions configuration'.

deepak_kadam’s picture

Hi there,

getting the error while clearing the cache:

Catchable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /includes/entity.inc on line 284 and defined in /includes/database/select.inc on line 1300

Solution:
https://drupal.org/files/drupal-1158114-51.patch
The patch at above link solve my problem.

Thank You.

helmo’s picture

The last submitted patch, 7: drupal.taxonomy_might_not_exist.patch, failed testing.

helmo’s picture

Version: 8.x-dev » 7.x-dev
Issue summary: View changes
Status: Active » Needs review
Issue tags: -Needs backport to D7

The patch from #7 still applies to D7, but D8 has changed substantially and is probably no longer affected.

So let's assume this is only a D7 issue... and just solve this

helmo’s picture

Status: Needs review » Needs work

The last submitted patch, 51: drupal-1158114-51.patch, failed testing.

helmo’s picture

Status: Needs work » Needs review
FileSize
608 bytes

Tss an offset of 5 lines :)
Here's a re-roll :)

ergophobe’s picture

#63 did the trick for me.

Running Drupal 7.24 with Panopoly on an otherwise fairly clean install (testing phase with basically no content).

helmo’s picture

Status: Needs review » Reviewed & tested by the community
3eidoz’s picture

Notice: Undefined index: controller class in /drupal/sites/all/modules/entity/entity.module on line 84 Warning: class_implements(): object or string expected in /drupal/sites/all/modules/entity/entity.module on line 84 Warning: in_array() expects parameter 2 to be array, boolean given in /drupal/sites/all/modules/entity/entity.module on line 84 Notice: Undefined index: schema_fields_sql in /drupal/includes/entity.inc on line 260 Catchable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /drupal/includes/entity.inc on line 279 and defined in /drupal/includes/database/select.inc on line 1300

please help

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 63: drupal-component-1158114-63.patch, failed testing.

David_Rothstein’s picture

Status: Needs work » Needs review
sinasalek’s picture

Patch #68 solved my problem for Drupal 7 latest version

schulle@web.de’s picture

Patch #68 solved my problem for Drupal 7.30

helmo’s picture

Status: Needs review » Reviewed & tested by the community

#67 was a test bot glitch ... I see multiple +1's so back to RTBC.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 63: drupal-component-1158114-63.patch, failed testing.

Status: Needs work » Needs review
dcam’s picture

Status: Needs review » Reviewed & tested by the community
David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs work

This seems a bit like it's hiding the bug more than fixing it... "base table" is (to my knowledge) a required property of hook_entity_info(), and the code in this function is expecting it to be accurate and to be able to use it.

I think we need to track down the root cause of the bug. There is discussion earlier in the issue of a few possible causes...

kevinquillen’s picture

This just happened to me recently on a Pantheon site, making it totally inaccessible WSOD. The patch indeed got me through, but as David says in #76, this just circumvents a root cause.

deanflory’s picture

Just ran into this when back-tracking to a backup due to drupageddon with an update to D7.33. Trying the patch...but clearly there needs to be a fix after 3.5 years.

I did not get the error on one site with far fewer modules than the second that has lots of modules and was stopped in it's tracks with this bad error.

srobert72’s picture

Patch #68 solved my problem for Drupal 7.34
As others said, I don't know if it the good solution or not.
But it needs a fix because this error really crashes sites and it's difficult to have a hand on them again.

kevinquillen’s picture

Yes - I feel that this simply hides the symptoms instead of fixing the root issue... it is hard to reproduce but it is a particularly nasty bug. Combined with caching layers like Redis and Varnish, once this gets up to memory cache it is very difficult to correct the issue (typically a cache clear - but it takes a lot more with corrupted cache bins).

lucyp’s picture

I just wanted to confirm that I had this bug too. For me it was dependent on the Rules module. With Rules installed, I would get this site-crashing error every time I would enable/disable a module. Clearing the cache with drush would fix it. With Rules uninstalled, I do not encounter this error at all.

I used the patch in #63/68 and can confirm that I no longer get the site-crashing error when I enable/disable a module.

I do, however get a few notices and warnings:

Notice: Undefined index: schema_fields_sql in .../sites/all/modules/rules/includes/rules.core.inc on line 56
Warning: Invalid argument supplied for foreach() in .../sites/all/modules/rules/includes/rules.core.inc on line 56
Notice: Undefined index: field cache in .../modules/field/field.attach.inc on line 634
Notice: Undefined index: revision in .../includes/common.inc on line 7761
Notice: Undefined index: revision in .../includes/common.inc on line 7761
Notice: Undefined index: revision in .../includes/common.inc on line 7761
Notice: Undefined index: load hook in .../sites/all/modules/entity/includes/entity.controller.inc on line 861

I don't really understand the finer points of what's happening here, but am just adding my 2 cents in case it helps solve the problem. Thanks to everyone who is working on this.

Cristina_Drupal’s picture

Could someone help me, please??. I've got this error:

Catchable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /home/calonso/public_html/inicial7/includes/entity.inc on line 279 and defined in /home/calonso/public_html/inicial7/includes/database/select.inc on line 1300

I deleted some modules of my file system (a big error, I know):

-Gmap
-Openlayers
-Address Field
-Geofield
-GeoPhp

And my website crashed.

Please, any solution. :(

winstonchurchil99’s picture

Upldate the drupal core to 7.41 release solve the bug for me:

drush rf
drush up drupal 
dasfuller’s picture

Running 7.44 and hit this bug hard on sites that use custom modules that are entity-heavy. Sites become absolutely unrecoverable. Applying patch #63 helped us get back online. Get this patch into drupal core as soon as possible please!

izus’s picture

Patch #63 worked for us too.
Thanks

marcelomg’s picture

Same problem happening, none of the patches worked for me.

Started happening after installing Brightcove module.

Drupal - 7.41

chrisrockwell’s picture

travis-bradbury’s picture

I'm just sharing my experience with this issue.

Suspiciously, I was only able to replicate this issue on one machine, not other instances of my project. The application would die pretty early on while expecting to have some data (['schema_fields_sql']['base table']) on rules_config. If I manually cleared the cache table I could watch it loading schemas. While calling all of the implemented hook_schema()s, It'd suddenly jump back to a breakpoint in entity_get_info(). Now it's trying to get schema information again but it's just loading from cache, which is incomplete since we never finished calling the hook_schema()s.

Turns out an error was being triggered in ldap_query_schema() because it was using an undefined constant. The error was logged by watchdog(), which invokes hook_watchdog(). Rules implements that and invokes an event, which requires reloading its information, ends up calling entity_get_info(), and we're getting our cached, incomplete entity information.

The constant was undefined because I had not installed the ldap extensions for PHP on that machine. Installing those appears to have fixed the issue.

So, if you're encountering this error, it could be helpful to look in drupal_get_complete_schema() to see if an error occurs while invoking each module's hook_schema().

This experience may be very different from what has caused the errors for others, but from my investigation it seems that changes such as in #63, where argument 2 to SelectQuery::fields() is forced to be an array, are not a solution since they'll only work around this error and allow the problem to be an issue later (such as in #81 where instead of the program crashing they're getting a bunch of less-fatal errors later in the program's execution).

Michael-IDA’s picture

love these six year old bugs ;(

New install of Commerce Kickstart, 7.x-2.44, https://www.drupal.org/project/commerce_kickstart

Added:

Administration menu, https://www.drupal.org/project/admin_menu
Wysiwyg, https://www.drupal.org/project/wysiwyg

Created Roles through PHP:

$role = new stdClass();
$role->name = 'Subscriber: Advanced';
user_role_save($role);

Even a double clear cache doesn’t help (‘drush cc all && drush cc all').

Site displays fine, but now PHP can’t get past drupal_bootstrap.

Here’s the errors, the first 3 REMOTE_ADDR have been around for years as well:

PHP Notice:  Undefined index: REMOTE_ADDR in /home/michael/public_html/site/includes/bootstrap.inc on line 3194
PHP Notice:  Undefined index: REMOTE_ADDR in /home/michael/public_html/site/includes/bootstrap.inc on line 3194
PHP Notice:  Undefined index: REMOTE_ADDR in /home/michael/public_html/site/includes/bootstrap.inc on line 3194
PHP Notice:  Undefined index: schema_fields_sql in /home/michael/public_html/site/includes/entity.inc on line 298
PHP Catchable fatal error:  Argument 2 passed to SelectQuery::fields() must be of the type array, null given, called in /home/michael/public_html/site/includes/entity.inc on line 317 and defined in /home/michael/public_html/site/includes/database/select.inc on line 1316

Edit:
PS: I can provide tarballs, 40MB total, if someone wants a known bad copy to work from.

Edit2:
Maybe. As a possible fix, try both clearing cache and running cron. I'm not sure which was run first, but problem vanished...

marysmech’s picture

I have experienced same problem on Drupal 7.54.

After little debugging I created patch that seem to fix the error.

helmo’s picture

Status: Needs work » Needs review
shaunole’s picture

I was able to validate this issue by executing the following drush command on the entity in question (In my case this was commerce_license):

drush php-eval "print_r(entity_get_info('commerce_license'));"

What I found was that the ['schema_fields_sql']['base table'] value was NULL as was the ['schema_fields_sql']['revision table'].
After clearing cache and forcing cron to run without halting on errors, the schema repopulated the base and revision table values. I was able to verify this using the above drush command again.

drush cc all
drush core-cron --no-halt-on-error

I'm not sure what caused the corruption of that schema data, but hopefully these steps help others in the pursuit of resolution.

arnoldbird’s picture

Version: 7.x-dev » 7.66
Priority: Normal » Critical

None of the above solutions are working for me. My site is down and I see no way to restore it. Drush won't run either. If I run "drush cc all", it hangs.

I'm experiencing this following an upgrade to 7.66. Rolling back database and code has not resolved the problem. The drupal_bootstrap() function never finishes executing, so I'm not able to do something like adding drupal_flush_all_caches() to index.php after the drupal_bootstrap() function call.

The error I'm seeing...

Notice: Undefined index: schema_fields_sql in /mypath/public/includes/entity.inc on line 298 Catchable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /mypath/public/includes/entity.inc on line 317 and defined in /mypath/public/includes/database/select.inc on line 1316

arnoldbird’s picture

Priority: Critical » Normal

Switching this from critical to normal because I was able to recover my site. I'm still trying to figure out how I might have resolved it, but I think it involved steps mentioned above, and then at a certain point I had to reboot mysql.

arnoldbird’s picture

Version: 7.66 » 7.67
Status: Needs review » Reviewed & tested by the community

Four and a half years ago in this thread, it was suggested that the patch in #63 hides the bug but doesn't find the root cause. That may be, but it doesn't seem like anyone is going to find the root cause, and the patch in #63 still works. Perhaps it should be committed so we don't have to patch entity.inc every time we do a core upgrade affecting entity.inc. Perfect is enemy of the good?

DamienMcKenna’s picture

Version: 7.67 » 7.x-dev
rcodina’s picture

Patch on #63 works for me and patch on #91 doesn't fix the problem. Also, patch available on #2673204: Argument 2 passed to SelectQuery::fields() must be of the type array, null given works for me too. I agree with @arnoldbird that patch on #63 should be committed ASAP. Thanks!

travis-bradbury’s picture

#81 vividly illustrates that the patch in #63 does not solve anything. Instead, it adds separation between the actual problem and its symptoms. Instead of the fatal error being discussed you will have different issues that will be at least severe, and possibly more severe because the application is broken but still running. What will it do?

It's likely that many of the reports of this problem were from totally different causes. It's possible that the only thing Drupal core can do to help here would be to reveal the problem earlier - crashing at the source of the problem instead of in the middle of the database api - but I have no idea if there's a practical way to do that.

skyredwang’s picture

Status: Reviewed & tested by the community » Needs work

We can't commit things that we know would cause more trouble in the future. Therefore, settings the status back

Ronino’s picture

This bug occurred to me when I called watchdog() in some hook_schema_alter() which caused Rules to trigger an event. It was gone after I removed the watchdog() call.

Here's the backtrace:

#0  DrupalDefaultEntityController->buildQuery() called at [/var/www/drupal/sites/all/modules/contrib/entity/includes/entity.controller.inc:170]
#1  EntityAPIController->buildQuery() called at [/var/www/drupal/sites/all/modules/contrib/entity/includes/entity.controller.inc:713]
#2  EntityAPIControllerExportable->buildQuery() called at [/var/www/drupal/sites/all/modules/contrib/rules/includes/rules.core.inc:237]
#3  RulesEntityController->buildQuery() called at [/var/www/drupal/sites/all/modules/contrib/entity/includes/entity.controller.inc:186]
#4  EntityAPIController->query() called at [/var/www/drupal/sites/all/modules/contrib/entity/includes/entity.controller.inc:249]
#5  EntityAPIController->load() called at [/var/www/drupal/sites/all/modules/contrib/entity/includes/entity.controller.inc:730]
#6  EntityAPIControllerExportable->load() called at [/var/www/drupal/includes/common.inc:8124]
#7  entity_load() called at [/var/www/drupal/sites/all/modules/contrib/entity/entity.module:259]
#8  entity_load_multiple_by_name() called at [/var/www/drupal/sites/all/modules/contrib/rules/rules.module:892]
#9  rules_config_load_multiple() called at [/var/www/drupal/sites/all/modules/contrib/rules/includes/rules.plugins.inc:835]
#10 RulesEventSet::rebuildEventCache() called at [/var/www/drupal/sites/all/modules/contrib/rules/rules.module:413]
#11 rules_get_cache() called at [/var/www/drupal/sites/all/modules/contrib/rules/rules.module:1055]
#12 rules_invoke_event() called at [/var/www/drupal/sites/all/modules/contrib/rules/modules/events.inc:200]
#13 rules_watchdog() called at [/var/www/drupal/includes/module.inc:965]
#14 module_invoke_all() called at [/var/www/drupal/includes/bootstrap.inc:2026]
#15 watchdog() called at [/var/www/drupal/sites/all/modules/custom/my_module/my_module.install:39]
#16 my_module_schema_alter() called at [/var/www/drupal/includes/module.inc:1171]
jpoesen’s picture

We had this exact issue today (2022-04-11, D7.88.

The approach in #93 worked for us: clear cache + run cron.

Still no idea what caused the issue in the first place.

Thanks, @shaunole!