After updating to latest 7.x-2.0-beta7 version something got stuck, not sure what happened exactly admin/config/system/cron is broken and shows
Fatal error: Call to undefined method stdClass::getPlugin() in .../sites/all/modules/ultimate_cron/ultimate_cron.job.inc on line 456
I did some debug and somehow last element of $jobs array looks like this:

 'ultimate_cron_plugin_launcher_serial_cleanup' => 
  stdClass::__set_state(array(
     'hook' => 
    array (
      'tags' => 
      array (
        0 => 'killable',
      ),
    ),
  )),

Therefore, it really tries to call undefined method since this is stdClass and not UltimateCronJob class. I've even tried downgrading to beta6 but problem seems now stuck, can't get rid of it. Removed all tables all caches, everything I figured is linked to Ultimate Cron but no avail.

CommentFileSizeAuthor
#5 ultimate_cron_job_load_all.txt50.59 KBvladan.me
#3 longbacktrace.txt1.01 MBvladan.me
#2 backtrace.txt686.59 KBvladan.me

Comments

gielfeldt’s picture

gielfeldt commented

Strange. The _ultimate_cron_job_load_all_raw() __should__ ensure that each job loaded is of the correct class.

Can you do 2 debug steps for me?

1.) drush php-eval "var_dump(_ultimate_cron_job_load_all_raw());"
2.) Give me stack trace from ultimate_cron.job.inc:456 (debug_backtrace)

Thanks

vladan.me’s picture

vladan.me commented
StatusFileSize
new backtrace.txt686.59 KB

1) # drush php-eval "var_dump(_ultimate_cron_job_load_all_raw());"
array(0) {
}
2) Not sure how useful in this format but still attaching output of backtrace.

vladan.me’s picture

vladan.me commented
StatusFileSize
new longbacktrace.txt1.01 MB
gielfeldt’s picture

gielfeldt commented

Thanks

I'll dive in to the debug info. In the meantime, what does this output?

drush php-eval 'var_dump(_ultimate_cron_job_load_all());'
vladan.me’s picture

vladan.me commented
StatusFileSize
new ultimate_cron_job_load_all.txt50.59 KB

No, thank you for taking time to look after this issue. :)
Attaching latest output.

vladan.me’s picture

vladan.me commented

That last one is somehow extra, shouldn't belong there...

gielfeldt’s picture

gielfeldt commented

Yeah, it's a bit odd. Well, it should be there, but it should be an UltimateCronJob class, and it should also be a bit more "verbose".

I can't say at this time what's wrong. I'll look some more into it later.

What about this:
drush php-eval 'var_dump(ultimate_cron_get_module_hooks("ultimate_cron"));'

vladan.me’s picture

vladan.me commented

It's also empty array
array(0) {
}

gielfeldt’s picture

gielfeldt commented

Now THAT's weird. That function should provide the cron hook info from Ultimate Cron. I know you said you cleared the cache, so it smells like there might be something wrong with the system/registry table. Though that doesn't explain where the stdClass object comes from.

Do you have any cron job configurations in the database (ultimate_cron_job) or exported to features?

vladan.me’s picture

vladan.me commented

I've disabled those module that have something to do with ultimate_cron (e.g. implementing hook_cronapi()) but nothing changed.
Next I've disabled all features that I have although they don't really have some information about cron, still nothing...

What I manage to debug is that stdClass object comes from launcher/serial.class.php

  public function cron_alter(&$jobs) {
    $class = _ultimate_cron_get_class('lock');
    if (!empty($class::$killable)) {
      $jobs['ultimate_cron_plugin_launcher_serial_cleanup']->hook['tags'][] = 'killable';
    }
  }

But I assume it was expecting UltimateCronJob object, since there was none it created new one (stdClass).

Finally, once this line is commented out, module somehow wakes up and shows all pages. And then after I uncomment that line, it works, problem solved, hm?
Immediately after uncommenting line I got tons (hundreds) of same notices
Notice: Array to string conversion in module_hook() (line 668 of .../includes/module.inc).

I guess it's from all those stale cron jobs that got run in same time.

I am also assuming it has to do something with order of execution because of "working scenario".

In the end, it works now but I still don't know what happened. Only good thing is that this problem is resolved (in a strange way) but for permanent solution, no idea really. I hope others won't have similar issue...

If I can be of any more help for you, please let me know.

Thanks for support!

  • gielfeldt committed dce848c on 7.x-2.x 
    Issue #2360209 by gielfeldt: Add sanity check to prevent stray class.
gielfeldt’s picture

gielfeldt commented

I'm not entirely sure what happened, but the cron_alter() that introduced the stdClass in the jobs array, may have blocked something somehow.

In any case, I've added a check for the presence of the job in question in that hook_cron_alter() and committed it to dev.

vladan.me’s picture

vladan.me commented
Status: Active » Closed (fixed)

Ok, thanks, I've tested with my "bad" database and after downloading latest development version of ultimate_cron it works without fatal errors. I am closing this issue.