By altv on

I installed the dtools module, and got the following:

NOTICE: Script execution completed with error: A session had already been started - ignoring session_start()
menu_execute_active_handler(): returned NULL - it's very bad!
WSOD detected! Checking for problems...
ERROR: menu_execute_active_handler() returned empty value!
Validating theme hooks...
Validation theme hooks completed.
Done.
Checking front_page() page callback...
ERROR: Callback: front_page() returned empty content!
NOTICE: router_item = Array ( [path] => front_page [load_functions] => [to_arg_functions] => [access_callback] => user_access [access_arguments] => a:1:{i:0;s:16:"access frontpage";} [page_callback] => front_page [page_arguments] => Array ( ) [fit] => 1 [number_parts] => 1 [tab_parent] => [tab_root] => front_page [title] => [title_callback] => t [title_arguments] => [type] => 20 [block_callback] => [description] => [position] => [weight] => 0 [file] => [href] => front_page [options] => Array ( ) [access] => 1 [localized_options] => Array ( ) [map] => Array ( [0] => front_page ) ) !
Cleared cache via cache_clear_all()
Cleared cache via drupal_flush_all_caches()
Rebuilded module cache.
NOTICE: Script execution completed with error: A session had already been started - ignoring session_start()
menu_execute_active_handler(): returned NULL - it's very bad!
WSOD detected! Checking for problems...
ERROR: menu_execute_active_handler() returned empty value!
Validating theme hooks...
Validation theme hooks completed.
Done.
Checking front_page() page callback...
ERROR: Callback: front_page() returned empty content!
NOTICE: router_item = Array ( [path] => front_page [load_functions] => [to_arg_functions] => [access_callback] => user_access [access_arguments] => a:1:{i:0;s:16:"access frontpage";} [page_callback] => front_page [page_arguments] => Array ( ) [fit] => 1 [number_parts] => 1 [tab_parent] => [tab_root] => front_page [title] => [title_callback] => t [title_arguments] => [type] => 20 [block_callback] => [description] => [position] => [weight] => 0 [file] => [href] => front_page [options] => Array ( ) [access] => 1 [localized_options] => Array ( ) [map] => Array ( [0] => front_page ) ) !
Cleared cache via cache_clear_all()
Cleared cache via drupal_flush_all_caches()
Rebuilded module cache.

Setting front module's status to 0 in system table doesn't help. Neither does deleting front module. Help!

Comments

mrudolph’s picture

mrudolph commented

I have a similar problem. I've looked at the log pages on the Godaddy hosting site without any clues. The content pages work fine, I can even edit or add content. But any invocation of an admin page (including site status or any other report) simply gives a WSOD - it looks like it's timing out altogether.

I used DTools and got this:

hook_exit wasn't executed properly at node, possible unexpected exit()/die()
Backtrace: n/a

One final note: remaining the sites/all/modules directory (so that the 3rd party modules couldn't be found) solved the problem of not being able to go to the admin pages - of course, it disabled all my features ... :-(

bearstar’s picture

bearstar commented

I have the same problem. All my admin pages come up as WSOD following the upgrade.

I renamed my /sites/all/modules directory, loaded the admin page, got this:

* One or more problems were detected with your Drupal installation. Check the status report for more information.
* warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'domain_content_menu_check' was given in /includes/menu.inc on line 452.
* warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'domain_content_menu_check' was given in /includes/menu.inc on line 452.
* warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'domain_nav_check' was given in /includes/menu.inc on line 452.
* warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'uc_authorizenet_silent_post_access' was given in /includes/menu.inc on line 452.

Then I renamed the directory back to its original name all was accessible again.

I did notice that cron was stuck (GoDaddy) so will put in a ticket with them.

Does that error message mean anything to anyone?

UPDATE: after GoDaddy unstuck the cron, everything seems to be in good shape again.

altv’s picture

altv commented

Thanks bearstar and mrudolph! I tried what you tried, and it worked. While the modules folder was renamed, the entire site white screened. Once I renamed it back to its correct name, however, both the site and the admin pages worked again, with one exception which I'll describe below.

I agree about cron being stuck. I have a GoDaddy reseller account (Wild West Domains) as well and found the same problem with cron as bearstar found. Even a manual run of cron would fail. I've also put in a ticket. I wonder what they will do to "unstuck" cron? And I wonder what this has to do with Drupal 6.14 looping after an upgrade?

I also see that a similar error to the error bearstar noted showed up in a custom module I have on the site and has not yet gone away. However, unlike bearstar's error, which shows up for "/includes/menu.inc on line 452" mine shows up for "/includes/form.inc on line 371". I wish I knew why. The error does not appear as a general alert on the admin pages. It just appears on the custom module page that collects user info and submits a standard Drupal form.

Also, the default theme, originally set to a custom theme, reverted to Garland.

UPDATE: Within about 10 minutes after I ticketed GoDaddy over the cron issue, cron began to work again. However, my custom module is still showing the error noted above. And yes, the custom module worked properly before the upgrade.

SECOND UPDATE: I discovered that the custom module was disabled by the above procedure. When I re-enabled it, the module began to work just fine.

mrudolph’s picture

mrudolph commented

Final entry on this topic: I disable all the contributed modules by renaming the entire directory to /sites/all/modules.old. I ran update until there were no error messages (2 times, I think). I then named the directory back to ../modules. This resulted in a working system again, including the admin directories.

Comments:

1) I did lose the scheduling field in the workflow of a couple of content types - easy enough to fix.

2) A review of all logs revealed that all my calls to the web site for pages in the admin area were coded as '200', ie, the request for the page was received and processed normally.

3) I can only conclude that some module was bolluxing the whole process and I have no idea which. They're all working fine now.