Closed (fixed)
Project:
Apache Solr Search
Version:
6.x-3.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
7 Sep 2012 at 16:05 UTC
Updated:
1 Oct 2012 at 20:51 UTC
Jump to comment: Most recent file
Comments
Comment #1
cpliakas commentedScreenshot of the error message.
Comment #2
cpliakas commentedThe attached patch handles the error condition and wraps the SQL in a try / catch block to handle errors not yet discovered. There is also a whitespace patch to more easily show what the proposed changes are.
Comment #3
dankobiaka commentedThis error brought down my entire site this morning. I can confirm it doesn't just effect admin/config/* pages.
Can the patch be added ASAP?
Comment #4
pwolanin commentedI'm a bit confused by this - what's the underlying SQL that's failing? Catching the exception seems a bit bogus - we should make sure the SQL is valid - it's probably just the IN condition with
array_keys($environments)We should also get rid of the db_table_exists() call in that function and move the ones in apachesolr_load_all_environments() - that's a potentially large performance hit for no good reason.
Comment #5
pwolanin commentedComment #6
cpliakas commentedYes, that is exactly what the patch in #1778150-2: Fatal error on all admin/config/* pages caused by SQL error in apachesolr_environment_load_subrecords() does. It handles the case that causes the invalid SQL. Then it adds a try / catch block just to make 100% sure a bad query doesn't happen so we don't find out about it by whitescreening.
Comment #7
anavarreJust want to confirm I'm having this issue too. For me it produced a non-recoverable WSOD (had to restore the DB) after disabling acquia_search.module because the "localhost" env was missing.
All details in dup: http://drupal.org/node/1782930
Comment #8
pwolanin commented@Chris - we shouldn't need to try/catch every SQL query. Is there something in this one particularly that's causing issues? Is this called from hook_init() and that's causing the issue?
If so, we should try/catch there, and not in this API function.
Comment #9
cpliakas commented@pwolanin, yeah, that's fine. I am honestly not sure where else it is called, but I just want to make sure we are handling any mistakes that we might not see right now gracefully. Clearly this issue is bigger than just your search pages, so I just want to be extra careful. The
$environmentsvariable is the one causing this bug, so if that is addressed then I am more than happy to have this committed and refine later.Thanks for the patch,
Chris
Comment #10
pwolanin commentedcommitted. need to see if backport is required for 6.x-3.x
Comment #11
pwolanin commentedHere's a quick port to D6
Comment #12
pwolanin commentedSomehow an extra function was patched.
Comment #13
pwolanin commentedcommitted to 6.x, though I'm seeing other unrelated issues.
Comment #14.0
(not verified) commentedUpdated issue summary.