Tuesday, April 05, 2016

iOS 9.x spotlight bug explained: It's the RAM.

Spotlight has been failing for me since I updated to iOS 9 - no results appear. It got much worse with 9.3. Force-quitting background apps, especially Reeder.app,  helps. It acts like a limited RAM bug, but I think there are ways Spotlight may fail.

From Apple Discussions it doesn’t hit devices with 2GB of RAM, it’s a problem for 1GB devices with lots of indexed content and/or memory hogging apps.

Jason Heiser has figured out what’s wrong (emphases mine). It’s a capacity/RAM problem:

Apple discussions April 5, 2016

My iPhone 6 updated to iOS 9.3.1 an hour ago and Spotlight Search is still broken for me.

I downloaded iOS Console and looked at the console output when trying to perform a Spotlight Search. Here is what I saw:

Apr 5 15:42:18 jPhone searchd[286] : (Error) IndexGeneral in si_playBackMobileRecords:2343: played back 0 records
Apr 5 15:42:19 jPhone searchd[286] : (Error) IndexGeneral in si_playBackMobileRecords:2343: played back 0 records
Apr 5 15:42:19 jPhone diagnosticd[83] : unable to find offset 0x81448aac in shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone diagnosticd[83] : unable to find offset 0x814467cc in shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone diagnosticd[83] : unable to find offset 0x81649da8 in shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone diagnosticd[83] : Invalid offset 2170854824 into shared cache for arch 'arm64'
Apr 5 15:42:19 jPhone ReportCrash[288] : platform_task_update_threads failed 1
Apr 5 15:42:19 jPhone ReportCrash[288] : Formulating report for process[286] searchd
Apr 5 15:42:19 jPhone ReportCrash[288] : report not saved because it is non-actionable
Apr 5 15:42:21 jPhone UserEventAgent[26] : jetsam: kernel termination snapshot being created
Apr 5 15:42:21 jPhone ReportCrash[289] : Saved type '298(298)' report (2 of max 25) at /var/mobile/Library/Logs/CrashReporter/JetsamEvent-2016-04-05-154221.ips

According to this, the searchd crash log is not being saved because it is "non-actionable." However, a log for "JetsamEvent" is being created at roughly the same time. I looked at this file on my iPhone and JetsamEvents appear to be a low-memory (RAM) issue. Here is the top portion of the crash report.


{"timestamp":"2016-04-05 15:42:21.21 -0500","bug_type":"298","os_version":"iPhone OS 9.3.1 (13E238)"}
{
"crashReporterKey" : "88540025a9600afa364c269a2c5bc8a91370b1ca",
"kernel" : "Darwin Kernel Version 15.4.0: Fri Feb 19 13:54:49 PST 2016; root:xnu-3248.41.4~28\/RELEASE_ARM64_T7000",
"product" : "iPhone7,2",
"incident" : "D0ED493F-7687-49D9-AFB9-BEE80BD93082",
"date" : "2016-04-05 15:42:21.21 -0500",
"build" : "iPhone OS 9.3.1 (13E238)",
"timeDelta" : 95,
"memoryStatus" : {
"compressorSize" : 50489,
"pageSize" : 4096,
"compressions" : 824422,
"memoryPages" : {
"active" : 101577,
"throttled" : 0,
"fileBacked" : 37711,
"wired" : 49311,
"anonymous" : 114469,
"purgeable" : 0,
"inactive" : 48272,
"free" : 2459,
"speculative" : 2331
},
"uncompressed" : 172172,
"decompressions" : 362924
},
"largestProcess" : "searchd",


According to this, the "largestProcess" was searchd when the crash report was generated. Further down in the crash report is searchd's information:


{
"rpages" : 129777,
"states" : [
"daemon"
],
"name" : "searchd",
"pid" : 286,
"reason" : "highwater",
"fds" : 100,
"uuid" : "7b301993-286d-3da5-a497-b729984d3229",
"purgeable" : 0,
"cpuTime" : 2.481274,
"lifetimeMax" : 84765
},

Apparently the maximum for searchd is "84,765" but it reached "129,777." The reason is "highwater" which I assume means searchd exceeded its RAM allotment. So maybe my Spotlight index is too large. Too many iMessages, too many songs, too many emails... Who knows.

The "report not saved because it is non-actionable" for searchd's crash report is worrisome. I fear this bug is nowhere on Apple's radar. We might be marginal outliers without recourse for a long time.

There are two workarounds for the bug:

  1. Force-quit background apps — may help free RAM. Try again.
  2. Siri works for launching apps even when spotlight fails.

I think setting all Spotlight indexing option to On helps — I have a feeling there’s a bug with rendering results that is worse if the rendering process has to manage exclusions. Restarting your phone daily probably helps too.

Update 7/30/2016

A correspondent who saw the same behavior as mine reported that Spotlight was working 8 days after he did a phone wipe and restore. I did the same and it’s working now 7 days later.  That doesn’t mean it will work forever, but 7 days is a long time. I’m now on iOS 9.3.3. I have seen a trustworthy report that the upgrade to 9.3.2 fixed the problem for some, for me it took the OS update and a wipe/restore.

 

6 comments:

redfood said...

I had this problem for weeks on an iPhone six. Neither quitting apps nor restarting the phone helped. Yesterday, I finally bit the bullet and did a backup on restore. It fixed the problem (at least for now).

Derick said...

wow the trick of turning ON all Spotlight indexing worked! I have been stuck without Spotlight 3+ months now & tried lots of "solutions" to no avail but finally it's back!

virtualess said...

After a week plus I m so so happy to agree that turning on all works!! It will skip a heartbeat once or twice but got back alive working and only happened twice. Thanks!!

JGF said...

Turning on all makes a difference at the margins, but I had do the full backup/restore under iOS 9.2.3

J said...

I still have this problem intermittently - it's a 7 with 10.3.1 .. :-(

JGF said...

Yikes! My 6s is behaving ok, but I'm sure I'll get bit again if Jacob has been hit on a 7. Prior to getting the 6s my 6 was again failing. I had to force quite background apps.