I spent a considerable amount of time tracking a bug yesterday but I wasn't able to spot the issue.
Basically I noticed that some keywords where not properly being show on the search results. By debugging the code, I found that they were being indexed fine and added to the search_index table, but not to the search_total table, so when the search performs an INNER JOIN, those keywords are not found.
I started debugging the search module, printing the found keywords along the indexing process and what I found is that the words were indexed just fine, but for some reason, when search_update_totals() was called, it didn't have any word to add to the table.
search_dirty() is used in both search_index() and search_update_totals(). The index flags the word being indexed on a static array in that funciton. For some reason, when the code gets to search_update_totals() the $dirty drupal_static() variable is empty, so the words are not added to the table.
I really don't get this. This is happening on my production server (nginx - php-fpm 5.4.45 and also on my local dev, osx apache php 5.4.45 as well). I tried this on a vanilla drupal install and this works just fine.
This happens both with "drush cron" or just lunching the cron.php as usual.
Even stranger, when I debug the code using phpstorm, the dirty drupal_static() array is not empty.
Any pointers would be appreciate. I actually ended up moving away from the builtin system and using search_api instead, but I do have a dump of the database with the error triggering in case someones wants to help me follow this up.
Comments
Comment #2
hanoiiComment #3
jhodgdonSo... I do not think this is a Drupal Core bug. I have never seen it reported before, and it doesn't happen in our automated tests or in your debugger, so I guess it is probably either a contrib or custom module causing problems or something like that. And we normally don't provide support for debugging things like that in the Core issue queue, but here are some ideas:
a) search_dirty() uses a drupal_static() in it... is it possible that something is calling a drupal_static_reset() on it somewhere?
b) This working right depends on the entire search_cron() procedure (and its function calls) being executed in the same process, with the same set of PHP memory. Is it possible that due to some PHP optimizations on your production server, something is being parceled off to a different thread? I really don't know if this is possible but there are a lot of cron processes that wouldn't work right if this was happening.
c) Does the behavior change when cron is triggered from, for instance, the status report page as opposed to from the command line in a server cron job? Because PHP sometimes has different settings when run from command line vs. under a web page request.
Anyway... I'm changing this to a support request and marking it fixed, because we don't really offer support here -- try IRC and other support mechanisms listed at https://www.drupal.org/support. Good luck! And if you do find it's Drupal Core, please add more information from your debugging and reopen this as a bug.
Comment #4
hanoii@jhodgdon your recommendations were spot on! I actually debugged every call to drupal_static() but I wasn't aware of drupal_static_reset(). Thanks!
Unbelievable, this is an issue with features, and a very important one IMHO. I submitted a patch for at it at least not to break core, but further work there is needed.
See #2603578-6: _features_set_export_language is clearing drupal static cache too aggressively breaking search and possible many other modules .
Thanks again!
Comment #5
jhodgdonWow. Yeah, they shouldn't do a blanket drupal_static_reset() during a cron run. They will (or could) definitely break other stuff that happens via shutdown processes, such as for instance the API module.... They should only drupal_static_reset their own variables.