Finder crashes in List View with large folder

Hi Cary Wolfson,

We understand that Finder is crashing when attempting to use List View to view your music. Does this only happen with music files? Let's have you start up your Mac in safe mode to see if the issue presents itself there. tarting in safe mode will take a little longer than normal, because it verifies and repairs the directory, cleans caches, and loads only Apple-critical items. Check out How to use safe mode on your Mac.

Cheers.

That's good news — hope they/you make some headway with it, and it gets fixed. It's a horrible bug.

I've made some very promising progress in the meantime. I'll include everything I've noticed, in case something here triggers useful thoughts for the people you talk to on Saturday.

1. If you start at a folder one level DEEPER than one of the problem folders, then navigate up to a problem folder, Finder will crash as expected, but when you relaunch it you'll start at the last happy state (i.e. that deeper folder).
2. If you have "View options" open when you relaunch Finder it will remain open, but you won't be able to interact with it, or even close it. You'll be able to click right through it, in fact — as if it's not there.
3. Other large folders that hadn't been in "List" view seem to work fine. No freezing, no need to relaunch Finder.
4. I'm running the beta SoftRAID driver (SoftRAID 6.0.1 b43) — this feels like it should make a difference, but keep reading, because I've found something more useful...

I can go to one of the troublesome folders, in List view (i.e. the things that normally lead to problems), and if I:

A: click in the folder and navigate using only the keyboard — it's fine.

B: click in the folder and navigate using only the scroll wheel of my mouse — it's fine.

When I two-fingered scroll using my trackpad, though — instant freeze.

Interestingly, if I do A or B, WAIT A WHILE, and then scroll with my trackpad, it's also fine.

I'd put (not a lot of) money on this being down to some new hybrid iOS/macOS view controller being a dick.

Another note:

I copied the problematic folders (just under 500GB of music, around 75,000 files) to another disk, and had the problem there too. When I deleted all of the .DS_Store files (find FOLDERNAMEGOESHERE -type f -name .DS_Store -print0 | xargs -0 rm <- please be careful with this), things improved. I've not touched the .DS_Store files on my main disk yet.

Could be a mix of two issues: the trackpad scroll and a corrupted .DS_Store file, perhaps.

Either way, it seems the steps to reproduce for me (maybe us both) could be:

1. Start with a large folder, filled with many other files (and folders in my case, though only 2 or three folders deep)
2. Switch to List view if you're not there already.
3. Select all.
4. Expand them all (right arrow).
5. Scroll through them for a while.
6. Close the window. ALL GOOD SO FAR, just slow.
7. Open a new window at some later point to a folder within that original large folder.

Option A: Scroll with the trackpad > Sadness ensues.

Option B: Scroll with the mouse > Life's ok, but don't touch that trackpad!

Questions for you, Cary:

— do you have SoftRAID installed?

— what are all of the app icons along the top of your Finder window? I don't have these, and have never seen them before. Wondering if it could be some utility that Finder doesn't like. To be clear, I do *not* have these, and have what seems to be the same problem as you, so it could be a red herring.

I have *exactly* the same problem as the OP, even down to how it started.

In the midst of some trouble-shooting steps now — what a way to spend the day :)

Edited to add: Big Sur 11.1, 2016 MBP with the files on the internal 2TB SSD, and no other connected peripherals.

I suspect this is being caused by embedded cover art in the music files.

I reproduced the behaviour you're seeing in a folder containing 138 folders with a total of 4,202 music files – a mix of mp3 and m4a format – many of which have embedded cover art.

In list view if I expand them all (with command+a then command+right-arrow) they will gradually all open after a few seconds but when I collapse them (with command+left-arrow) Finder hangs.

I took a sample of the non-responsive process which has this:

Process:          Finder [26186] [unique pid 224967]
UUID:             CCBC859B-DCAE-366E-9456-CE2C7DC1B5A8
App Version:      11.1
Build Version:    1350.2.10
Path:             /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder
Architecture:     x86_64
Parent:           launchd [1]
UID:              501
Footprint:        218.12 MB
Time Since Fork:  502s
Num samples:      794 (1-794)
CPU Time:         0.005s (14.5M cycles, 3.8M instructions, 3.81c/i)
Note:             Unresponsive for 260 seconds before sampling
Dispatch Thread Soft Limit Reached:   64  (too many dispatch threads blocked in synchronous operations)
Dispatch Thread Hard Limit Reached:  512  (too many dispatch threads blocked in synchronous operations)

Those final thread limit warnings are followed by 448 copies of the following (this is the last example):

Thread 0x45c70f    DispatchQueue "TIconFetcher Group Queue: 35 nodes"(1759)    794 samples (1-794)    priority 37 (base 37)    cpu time <0.001s (345.6K cycles, 64.8K instructions, 5.33c/i)
  794  start_wqthread + 15 (libsystem_pthread.dylib + 9319) [0x7fff20336467]
    794  _pthread_wqthread + 244 (libsystem_pthread.dylib + 13395) [0x7fff20337453]
      794  _dispatch_worker_thread2 + 92 (libdispatch.dylib + 77752) [0x7fff2019efb8]
        794  _dispatch_root_queue_drain + 326 (libdispatch.dylib + 75863) [0x7fff2019e857]
          794  _dispatch_async_redirect_invoke + 713 (libdispatch.dylib + 22632) [0x7fff20191868]
            794  _dispatch_continuation_pop + 543 (libdispatch.dylib + 25101) [0x7fff2019220d]
              794  _dispatch_client_callout + 8 (libdispatch.dylib + 14279) [0x7fff2018f7c7]
                794  _dispatch_call_block_and_release + 12 (libdispatch.dylib + 9693) [0x7fff2018e5dd]
                  794  ??? (Finder + 2694486) [0x109167d56]
                    794  ??? (Finder + 518274) [0x108f54882]
                      794  usleep + 53 (libsystem_c.dylib + 494476) [0x7fff20285b8c]
                        794  __semwait_signal + 10 (libsystem_kernel.dylib + 14262) [0x7fff203087b6]
                         *794  semaphore_wait_continue + 0 (kernel + 885280) [0xffffff80002e8220]

I'd take a punt that 'TIconFetcher' is responsible for loading the cover art images and showing them as icons and it's overloaded as the folders open, then if you also ask it to stop and figure out which ones to not worry about as the folders are closed it all screams to a halt until the queue sorts out which way is up..

Interestingly with the folder copied to a Samba share I get very slow performance but it does NOT hang Finder and a grey Loading spinner I haven't seen before appears on the window. Perhaps the latency of the network gives Finder enough time to juggle the requests in a more reasonable way?

To test this I duplicated the folder and removed all of the embedded album art from the files (which resulted in a drop in size from 143GB to 87GB!) which resulted in fairly quick performance expanding the folders and a slight hang (a few seconds of beachball) when collapsing them.

Chunking through 56GB of image data to get tiny thumbnails for thousands of files in real-time is a clearly a bit of an ask but some more graceful feedback, like the loading spinner on the network example, would be nice to have.

Interesting! The plot thickens :)

Another candidate is that it's performance related, then. Agreed with jimmykl that it's hardly a minor ask to have the Finder do what we're asking, but Apple have options here. Better feedback with a spinner. A front-end that stops us doing this sort of thing (or handles it differently). I'm not bright enough to know what's going on, but it's not been a problem before Big Sur, so I'm assuming *something* has changed.

@Cary, are you using a mouse with your iMac that lets you scroll horizontally as well as vertically? Most modern examples from Apple do. I wonder if what I see with the reproducible trackpad behaviour is related to what jimmykl sees with the embedded album art, i.e. it's more work for the Finder and all its underlying system services to juggle redraws on two axes (x and y) — since when I use the keyboard and the scrollwheel on my Logitech mouse I'm only giving it up and down to deal with. It's really hard to scroll ONLY up and down with a trackpad, or using a recent Apple mouse :-P

That at least leaves the trackpad (and some mouse models) theory standing. Trying another simpler mouse (just a scroll wheel) would be a good one to be able to mention to the Apple people tomorrow, since the Magic Mouse would likely cause the same problematic behaviour as a trackpad (mix of left/right and up/down scrolling).

Understand that most people have something better to do with their lives though, ha!

If in the meantime you got bored and wanted to have a nose around at .DS_Store files, get to the folder you want in Terminal, and type:

ls -a

Plain old "ls" won't show hidden items. Also, that command I posted doesn't eliminate them globally, only inside the folder you've navigated yourself to in Finder, and deeper. This was fine for me, since the folders only contained music files. Nothing that made me worry, and I'm both a bit of an amateur at all of this, and a capable worrier!

In case anyone else wants that command again without wading through the thread:

find FOLDERNAMEGOESHERE -type f -name .DS_Store -print0 | xargs -0 rm

Looking forward to what you hear tomorrow, Cary — great that you'll be talking to them.

Interesting!

Have you tried removing all of the .DS_Store files on *the external drive's version* of that folder, restarting, then giving it another go?

Hope you got your problem solved, Cary. Would be great to hear what you found out when you have time to post again.