SpamSieve 3.2.1
SpamSieve 3.2.1 is a maintenance release of my Mac e-mail spam filter.
This fixes the previously mentioned problem with AppleScript timeouts and POP accounts on macOS Tahoe 26. I found a workaround, but it’s still a mystery exactly what was causing the problem. First, why was AppleScript delaying and then timing out rather than just reporting an error? I still think there’s a general Tahoe issue that causes this in a variety of apps. Second, what is the underlying error and why does it only affect some POP accounts? I was not able to find any pattern in the configurations that were getting the error vs. working normally.
Oddly, with macOS 15.7, I got a few reports of
errAETimeoutwith the Mail extension talking to SpamSieve. This had never happened before, and, again, there did not seem to be evidence that the target app was actually delayed in responding to AppleScript. It seems unlikely, but it’s almost as if whatever’s going on with AppleScript in Tahoe got backported to Sequoia.NSStatusItemin Tahoe is sending KVO notifications that it became visible even when it’s been set to be hidden (and seemingly is correctly hidden).I’ve been using
Thread.callStackSymbolsto stash some context information in my errors, but I had to reduce this practice because sometimes_NSCallStackArray(the lazy class that calculates the symbols) is many times slower than normal and was blocking real work from getting done.I continue to receive occasional reports of Core Data crashes in
_thereIsNoSadnessLikeTheDeathOfOptimism, where it seems like there’s no constraint conflict or optimistic locking failure, just a damaged database file. It’s unfortunate that Core Data can’t report this as a normal error when saving and instead takes down the whole app.
Previously:
- How to Export a Mac .icon File With the Proper Margins
- Tahoe AppleScript Timeouts
- macOS 15.7 and macOS 14.8
- SpamSieve 3.2
5 Comments RSS · Twitter · Mastodon
The issue with callStackSymbols is Swift, as it converts to strings at the ObjC->Swift berrier. Instead, take the addresses (the other Array API), and translate on demand. I have a better replacement, that demangles C++ and Swift symbols:
https://github.com/LeoNatan/LNObjectiveCHelpers/blob/master/LNAddressInfo.mm
There is also a private API to initialize the special NSArray subclass with the addresses when you really need them.
@Léo I’m aware of the eager bridging, but that has previously not been a problem for me, and it seems like it could be defeated by preventing/delaying the conversion to Array (e.g. casting to NSArray), without having to demangle them yourself. Thanks for you solution, though. I think the main issue is that in rare cases the demangling is super slow. I’m not sure what causes that, though.
Yes, if you manager to preserve the NSArray and travel with that, it should not fire the symbolication. I'm not familiar with bugs in that flow, as theoretically, the data exists in the Mach-O and the cost should be the string allocations.
@Léo I tested this, and it works to just cast to NSArray when receiving the value in Swift. Here’s the bottom part of the slow sample:
1722 backtrace_symbols (in libsystem_c.dylib) + 108 [0x7ff80fbdacaa]
1722 dyld4::APIs::dladdr(void const*, dl_info*) (in dyld) + 206 [0x7ff80f9f6a78]
1722 dyld3::MachOLoaded::findClosestSymbol(unsigned long long, char const**, unsigned long long*) const (in dyld) + 320 [0x7ff80fa14888]
Looking at source ( https://github.com/apple-oss-distributions/dyld/blob/9307719dd8dc9b385daa412b03cfceb897b2b398/common/MachOLoaded.cpp#L606 ), it is traveling the MachO headers. I wonder what is causing it to slow down.
