Spotlight indexing crashes on time machine backups

[stanft]

Hi everyone,

suddenly, the Spotlight indexing on my MacBook Pro M2 Max with macOS Sequioa 15.2 crashes repeatedly. The console is full of crash reports from the mds_stores process. And it seems that the time machine backups are the ones that cannot be indexed properly anymore.

It is always the same function and the same "invalid address" that causes it to crash with a EXC_BAD_ACCESS (SIGSEGV). I have attached parts of the crash log below.

I have done nearly everything to get rid of this problem:

• Deleted the existing backup (on an SMB share) and performed several initial backups
• Deleted the Spotlight indexes and rebuilt them
• Deleted the time machine settings completely
• Reinstalled macOS Sequioa
• Performed a file system check with no problems
• Performed a hardware test which did not find anything wrong either
• Performed an initial backup on another target (external HDD)

Nothing has changed anything. The mds_stores process crashes reproducible as soon as the first incremental backup has been performed. This results in large disk write amounts as macOS tries to reindex from scratch everytime. And in addition, after several attempts, Spotlight stops working altogether.

I am about to wipe the whole MacBook and perform a clean installation, but I am not sure whether this will change anything as this might be a bug in macOS Sequioa. Has anybody else here experienced something similar?

Best regards,
Stephan

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               mds_stores [23951]
Path:                  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds_stores
Identifier:            mds_stores
Version:               ???
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               0

Date/Time:             2024-12-31 10:25:33.3690 +0100
OS Version:            macOS 15.2 (24C101)
Report Version:        12
Anonymous UUID:        9E8E75A2-C76B-A3C6-8084-A11F3F0B4603

Sleep/Wake UUID:       AD5B86EF-7199-4503-8787-9D1E2442CAA7

Time Awake Since Boot: 64000 seconds
Time Since Wake:       8144 seconds

System Integrity Protection: enabled

Crashed Thread:        8  Dispatch queue: */S

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000060
Exception Codes:       0x0000000000000001, 0x0000000000000060

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [23951]

VM Region Info: 0x60 is not in any region.  Bytes before following region: 4372021152
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
---> 
      __TEXT                      10497c000-1049c0000    [  272K] r-x/r-x SM=COW  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds_stores

Thread 8 Crashed::  Dispatch queue: */S
0   SpotlightIndex                           0x1b7af6f8c processVectorIndexDumpContexts + 796
1   SpotlightIndex                           0x1b7963eec mergeIndexData + 3384
2   SpotlightIndex                           0x1b7b8b4e4 _ContentIndexMergeIndexes + 352
3   SpotlightIndex                           0x1b7962f1c ContentIndexMergeIndexes + 320
4   SpotlightIndex                           0x1b79621a4 InnerMerge + 2336
5   SpotlightIndex                           0x1b79613b8 OuterMerge + 2116
6   SpotlightIndex                           0x1b7960724 MergeIndexes + 684
7   SpotlightIndex                           0x1b795cd1c si_mergeIndex + 2644
8   SpotlightIndex                           0x1b790cd7c compaction_runLoop + 148
9   SpotlightIndex                           0x1b7b622e8 work_fun_inner + 1020
10  SpotlightIndex                           0x1b78c655c work_fun + 68
11  libdispatch.dylib                        0x19c9249a0 _dispatch_block_async_invoke2 + 148
12  libdispatch.dylib                        0x19c9155b4 _dispatch_client_callout + 20
13  libdispatch.dylib                        0x19c91cbd8 _dispatch_lane_serial_drain + 768
14  libdispatch.dylib                        0x19c91d764 _dispatch_lane_invoke + 432
15  libdispatch.dylib                        0x19c91ca38 _dispatch_lane_serial_drain + 352
16  libdispatch.dylib                        0x19c91d764 _dispatch_lane_invoke + 432
17  libdispatch.dylib                        0x19c91e7dc _dispatch_workloop_invoke + 736
18  libdispatch.dylib                        0x19c9289a0 _dispatch_root_queue_drain_deferred_wlh + 288
19  libdispatch.dylib                        0x19c9281ec _dispatch_workloop_worker_thread + 540
20  libsystem_pthread.dylib                  0x19cac43d8 _pthread_wqthread + 288
21  libsystem_pthread.dylib                  0x19cac30f0 start_wqthread + 8

 

[stanft]

I have just recreated the Spotlight index for all volumes again. As before, the index was generated without problems for all internal volumes, but as soon as the time machine volume is indexed, the mds_stores process crashes again.

Below are the log messages just before the crash:

2024-12-31 13:50:04.354509+0100 0x27db5d   Default     0x0                  42102  0    mds_stores: (SpotlightIndex) [com.apple.spotlightindex:CI] index[0] indexID: 21 for 0 update: yes
2024-12-31 13:50:04.354520+0100 0x27db5d   Default     0x0                  42102  0    mds_stores: (SpotlightIndex) [com.apple.spotlightindex:CI] createIndex(<private>) VectorIndex not supported on <private> isLocalVolume: 0, isBackup: 0
2024-12-31 13:50:04.355243+0100 0x27db5d   Default     0x0                  42102  0    mds_stores: (SpotlightIndex) [com.apple.spotlightindex:CI] create indexid 21 <private>
2024-12-31 13:50:04.356329+0100 0x2805a6   Default     0x0                  42102  0    mds_stores: (SpotlightIndex) [com.apple.spotlightindex:IVFVectorIndex] [<private>] close 0x131ecc548 with prefix <private>
2024-12-31 13:50:04.358643+0100 0x27db5d   Default     0x0                  42102  0    mds_stores: (SpotlightIndex) [com.apple.spotlightindex:IVFVectorIndex] [<private>] createVectorIndexDumpContext: 0x131ecc7e8 <private>
2024-12-31 13:50:04.359045+0100 0x27db63   Error       0x0                  42102  0    mds_stores: (SpotlightIndex) exception handler not resolved for thread 0x1703 addr 0x60 reason 3

The log entries are identical for each crash.

Does anybody have a guess what might be going wrong here? The strange thing is: On my work MacBook Pro (M3 Max) the time machine backup works fine.

And if I remember correctly, the crashing has started after removing the initial time machine volume and restarting the time machine backup from scratch. This was the quickest way to free up space on the time machine volume. Maybe the initial backup is too large (around 900 GB)?

Best regards,
Stephan

 

[Fishrrman]

Here's something to try. I make NO promises.

You may want to STOP Spotlight from indexing that drive, forever.
I'm going to GUESS that if the "mds_stores" process isn't running to begin with, then it can't crash.

This MIGHT work. It's worth trying.

a. Open the TextEdit app
b. Create a new, empty file
c. Enter a little text (doesn't need to be more than a few words, any will do). I suggest "stop spotlight indexing"
d. Now, give this file the exact name:
.metadata_never_index

IMPORTANT: note that the filename begins with a period. This will MAKE IT INVISIBLE once it is created. This is what we want. The finder may warn you about this, just "click through" and continue.
Also, include the underscores.

The file MUST be saved "at the root level" of the drive (NOT in any folder).

Reboot.

Spotlight should now ignore the drive -- no indexing.
Again, I'll GUESS that because of this, mds_stores won't affect it.
No mds_stores [might] = no crash.

One other thing:
On the Mac, you can type "Command-Shift-." (again note the period) to "toggle on and off" visibility of [normally] invisible files. Just to verify whether or not the new file you just created "is there"...

If you try this (it's really very simple), let us know if it helped.

 

[gilby101]

You may want to STOP Spotlight from indexing that drive, forever.

I know this doesn't bother you because you don't use TM and have probably not tested your solution, but:
1) The TM volume is read only - you can't add a .metadata_never_index file.
2) You need to describe the mdutil method (if you know that works with TM disk).
3) Stopping indexing (if you can) compromises some of TM functionality when doing restores.
4) Does TM automatically re-enable indexing?

The log entries are identical for each crash.

I have had one mds_stores crash (very like yours) in the past week. Time stamp suggests it is not related to Time Machine. I did not notice ill effects (like re-indexing). This is for 2019 iMac.

 

[stanft]

You may want to STOP Spotlight from indexing that drive, forever.
I'm going to GUESS that if the "mds_stores" process isn't running to begin with, then it can't crash.

I don't think that this will work as Spotlight indexing is required for Time Machine backups to work properly. Therefore, it is not possible to deactivate Spotlight indexing for Time Machine volumes.

 

[stanft]

I have had one mds_stores crash (very like yours) in the past week. Time stamp suggests it is not related to Time Machine. I did not notice ill effects (like re-indexing). This is for 2019 iMac.

But did the crash happen on a thread indexing a Time Machine volume?

 

[stanft]

It seems that I have finally found a way to solve this problem. The initial backup size seems to be the culprit. If the first initial and incremental backup has been performed, Spotlight creates an initial index for the Time Machine backup. If this first backup is too large, then the index merge process fails and the mds_stores process crashes.

To test this, I have set up a virtual machine with a blank macOS Sequioa. On this virgin system, the Time Machine backup and Spotlight indexing work as expected.

So I came to the conclusion that maybe the initial backup size is the problem. I changed the Time Machine settings and excluded nearly everything from the backup so that it only had a size of a few gigabytes in total. As expected, the Spotlight indexing worked perfectly fine. After the initial indexing, I then added the missing backup content without problems as the initial Spotlight indexing (and the problematic merge index) is not performed anymore for the upcoming incremental backups.

I guess that this is a bug in macOS, but it occurs very rarely as most users start the initial Time Machine backup directly after the initial setup of macOS ... with no data on the system yet.

 

[jorgk]

See this discussion and my struggle. For now, it seems to be solved (for me) by using Migration Assistant to import -only- the user data again from a Time Machine backup. Migration Assistant will ask for a new Username in the process.