In install_drupal()
, when an exception occurs in the try block, it is caught and displayed to the user using install_display_output()
.
install_display_output()
winds up calling menu_get_item()
where the path $ancestor
array is found empty but nevertheless used in a query, which leads to an invalid SQL query (WHERE path in ()
).
This behavior is triggered when the installation profile contains errors.
An abbreviated debug back trace looking back from menu_get_item()
looks something like this:
install_display_output()
uses
template_preprocess_maintenance_page()
to render the error page. Then a call to
drupal_get_title()
retrieves the active title with
menu_get_active_title()
which in turn calls
menu_get_item()
.
Full debug back trace is attached.
Screenshot of the error message:
http://skitch.com/alexbarth/dwxr2/re-installation-error
Full error message:
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://localhost/rw/install.php?profile=myprofile&locale=en&id=1&op=do StatusText: Service unavailable (with message) ResponseText: 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 ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 426 of /opt/local/apache2/htdocs/rw/includes/menu.inc).
Patch coming.
Comment | File | Size | Author |
---|---|---|---|
#23 | fail_fail_fail.patch | 534 bytes | catch |
#23 | pass_pass_pass.patch | 1.79 KB | catch |
#11 | move_menu_rebuild.patch | 1.26 KB | chx |
#7 | install.patch | 849 bytes | catch |
#5 | 898634-install_display_output.patch | 959 bytes | catch |
Comments
Comment #1
alex_b CreditAttribution: alex_b commentedHere is a first shot at the patch. It exits menu_get_item() in case the $ancestor is empty. Seems reasonable as there can't be a menu item if there are no ancestors in the path. I am definitely not sure about this approach though and would appreciate guidance.
With this patch applied, I get a useful error message: http://skitch.com/alexbarth/dwq5p/installing-drupal-drupal
BTW, to reproduce this error, just add book module right after 'block' in the minimal installation profile:
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedWould it be possible to prevent the maintenance page from getting there in the first place?
Comment #3
alex_b CreditAttribution: alex_b commentedGood question. I don't know.
Comment #4
catchWe could also stop template_preprocess_maintenance_page() calling drupal_get_title() during the install process (or do a drupal_set_title() which would stop it hitting th Or having the installer do a drupal_set_title() would also prevent it trying to find a menu item. e menu system)
Also I don't think this is critical, it makes it (even more) annoying to debug an install profile with errors in it, but that's not in itself a critical bug.
Comment #5
catchHere's a patch doing the drupal_set_title(), untested.
Comment #6
David_Rothstein CreditAttribution: David_Rothstein commentedI haven't tested it either, but I know it won't work because there's no 'interactive_task' in the installer - it's just 'interactive' :)
Also, isn't this code in the wrong place? Looks like this would set the title on all installer pages, not just error pages. I'm guessing this would need to go inside install_drupal() itself, when the exception/error is caught. And even then, since this error seems to occur during an AJAX request as part of the batch, I'm not sure the title would ever be displayed (although I guess we don't care that much).
I think the approach of displaying a custom title makes sense, but it also seems reasonable to try to fix the underlying menu system bug. menu_get_item() really shouldn't die unexpectedly like that, should it?
Comment #7
catchdoh, that's where I meant to put it, don't know what I was thinking when I actually wrote the patch.
I'm trying to think if I've seen this error anywhere other than installation, possibly when there was an error during a menu_rebuild() you could run into the same thing.
Comment #8
alex_b CreditAttribution: alex_b commentedThat was also my thinking. Is there an inherent problem with #1?
Comment #9
David_Rothstein CreditAttribution: David_Rothstein commentedCame across a related issue with a similar patch as #1: #910400: SQL error in menu_get_items when menu items has no ancestors and router item is not in cache.
It sounds to me like something along those lines is the correct fix.
Comment #10
alex_b CreditAttribution: alex_b commentedNote: the error can't be reproduced as described in #1 anymore. But pretty much any fatal error when installing modules or in hook_install() seem to provoke it.
For instance, add
throw new Exception('This is broken');
to the end of minimal_install() and install. The error message won't say that the Test Exception, but report the PDOException.#7 fixes the problem. (It has btw the exact same effect on the resulting error message like #1: http://skitch.com/alexbarth/d4sks/installing-drupal-drupal).
From my point of view this is RTBC. In light of #9 this should probably be run by menu system maintainers, hence setting this to NR and menu system.
Comment #11
chx CreditAttribution: chx commentedHow about this?
Comment #12
chx CreditAttribution: chx commentedOn a second thought #7 is good too but is it enough? I somewhat think that both patches will be needed.
Comment #13
alex_b CreditAttribution: alex_b commented#11 fixes the reported problem. I like the approach as it solidifies menu_get_item().
IMO, "Errors during installation." message is not strictly needed from a UI point of view, hence I would avoid the extra code - see: http://skitch.com/alexbarth/d4a38/installing-drupal-drupal
The messages would actually need some better formatting, but that's a different story.
I'd say #11 is RTBC.
Comment #14
chx CreditAttribution: chx commentedI would say let's wait for pwolanin before committing.
Comment #15
pwolanin CreditAttribution: pwolanin commentedThere will be some minor overhead to this change (a few extra calls per page to variable_get()), but it seems like a reasonable change if it makes the overall code more robust.
Comment #16
kattekrab CreditAttribution: kattekrab commentedError
The website encountered an unexpected error. Please try again later.
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 ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 426 of /home/cats/Sites/drupal/includes/menu.inc).
Trying to install D7 B2 - got this error.
Using the 'standard' install profile - entered all the database credentials then clicked next and that's what happened. @cafuego suggests that this might be helpful: http://pastebin.com/qNGV0W4S - that's a list of tables that had been created at that point. The actual error seems to have been caused by the lack of ancestors on the menu item.
Somewhat strangely though after clicking back and doing it again, I progressed to the next screen. However after entering site details and maintainer account details I get the WSOD. When I try to view the site front page, I get page not found.
This is on Ubuntu 10.04 with PHP 5.3.2 and MariaDB.
The same problem does NOT occur when installing on Ubuntu 8.04 with PHP 5.2.10
Comment #17
kattekrab CreditAttribution: kattekrab commentedupdate against D7 Beta-2
Comment #18
David_Rothstein CreditAttribution: David_Rothstein commentedThe patch still applies - setting this back to its original status.
Comment #19
kattekrab CreditAttribution: kattekrab commentedThat patch didn't fix my issue - so am re-opening http://drupal.org/node/910400
See - http://drupal.org/node/910400#comment-3622670
Comment #20
David_Rothstein CreditAttribution: David_Rothstein commentedSorry, somehow I only noticed your comment in #17, not #16.
I can't reproduce that error myself, but it does seem like the patch fails to protect against a path that has no ancestors. This could happen if menu_rebuild() gets called early enough and does not result in the 'menu_masks' variable actually getting populated...
Something like a combination of the patches in #1 and #11 might be reasonable. There can't be any good reason for this function to ever attempt a query that uses IN() under conditions when we know it will fail.
Comment #21
boombatower CreditAttribution: boombatower commented#11 fixes the issue when an install profile calls taxonomy_term_save() when creating forums.
Comment #22
sunComment #23
catchI'm not sure why this was marked down from RTBC. There is no indication from kattekrab's post that they ran through the whole process again with the patch applied, I don't think it can be expected to fix an update that's already hosed, so this extra case is 'needs more info' until we have more information IMO.
The installer issue is fixed by #11, and the patch makes sense in itself.
I'm uploading a test that should fail without the patch applied, then #11 plus the test.
Comment #24
chx CreditAttribution: chx commentedWe moved menu_get_item up in the bootstrap process we need to move the omfg rebuild up higher as well. Correct patch.
Comment #25
webchickCommitted and pushed to 7.x and 8.x. Thanks!
Comment #27
David_Rothstein CreditAttribution: David_Rothstein commentedIt seems like the patch committed here is causing some interesting issues. See #1232346: Easy to trigger multiple menu rebuilds per page (including infinite recursion) via menu_get_item() since 7.12