TotalFinder is always crashing when MacBook Pro boots

TotalFinder
1

Lately, every time I boot or reboot my machine, TotalFinder 1.9.4 crashes. I send in the crash report via the auto reporting email but I thought I would also post here in case others are having the same problem. Let me know if you need any other Console logs. The auto generated email is:

TotalFinder 1.9.4 crashed in [TApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (Tabs) | v10.12.5, OS 16F71b, bad access, thread 12

Hi Antonin,

My TotalFinder just crashed! TF seems to crash every time I restart my MacBppk Pro.

The crash report is available here:

You may help me fix the problem by describing what happened before the crash.
I appreciate your help and I read these crash reports, but don’t expect my direct answer.
For further discussion please open a topic at
https://discuss.binaryage.com.

Thank you, Antonin

2

Hi Jim,

Thanks for reporting this, but I cannot help from this crash report. It looks like it is not necessarily TotalFinder’s fault. The crash happened on thread #12 which has no traces of TotalFinder code.

Can you confirm this crash does not happen when you boot with normal Finder? (remove TotalFinder from Login startup items)

3

I apologize for not getting back to this faster. I did as you suggested and when TF is not auto-installed, the Finder doesn’t crash during startup. I admit to not understanding a lot of data displayed in Console logs. I am more of what I call an “educated guess” debugger. I first guessed that the order that my startup items loaded at startup could be a problem. TF was the last thing loaded at startup so I decided to test what would happen if it was first. Unfortunately you cannot just change the order of the startup items so I removed everything listed and added them back with TF first. Since then neither the Finder nor TF crashes at startup. I guess I solved the problems but I honestly don’t know why the order of loading startup items “fixed” the crashing. So my issue has been solved.

4

Thanks for getting back to us, Jim.

Frankly, there may be subtle assumptions in Finder and TotalFinder could break some of them. Especially asynchronous code running on other threads could be tricky. Because normal Finder code could use a lock to protect some data while it is being worked on multiple threads. Unfortunately TotalFinder might not be aware of it and do some work during initialisation phase which would trigger some Finder work without using those locks (because it is unaware they exist). This could cause rare crashes, usually due to specific timing of operations. You might be hitting one of those. But this is just a theory. There might be something else in play.