SpamSieve locking up under Sonoma

I run SpamSieve on a stand alone Mac mini with 3 email accounts using Apple Mail.

I’ve been suing SpamSieve for a long time and upgraded to v3, running it for a few days then upgrading Mac mini to Sonoma.

At first I had a problem with not catching any spam, but by turning on filtering on two of the accounts. A little slow but works.

Now I will see a lot of spam in inbox and login to my Mac mini and find Spamsieve locked up. I force quit and restart a couple of times, I get it working normally for a while.

The Mac mini is bare bones, only dropbox and Inkjet Plumber running.

Any ideas out there, I get 100+ emails a day which Spam Sieve gets 99.99% when its running.

Please record sample logs from Mail and SpamSieve when this happens so that we can see what’s causing this.

I too am having this issue. At first everything was perfect (for about 2 weeks after install of spamsieve)
Now the last 2 days it locks up as it gets spam mail, runs fine until a few come in, then I have to force quit. I’ve sent the test sample to technical support as was instructed at the beginning of this post. It has become completely unusable because of this.

I’ve not yet heard back from @mlmcclaskey. The hang that @scphillipp1 is seeing seems to caused by a certain message that’s triggering a performance bug in Swift Regex when matching against the blocklist or allowlist. (Prior to Sonoma, macOS uses the ICU regex engine, which doesn’t seem to have this problem.) Please use the Save Diagnostic Report command in the Help menu and send me the report file, as described here, and I’ll investigate which rule is implicated and see what can be done.

Has not locked up since my initial email.

According to Log it was one email four times that caused the crash. I don’t know if it was the One email that I finally deleted on another device or that it was four separate emails.

I am uploading the Raw source file and screenshot.

Raw Source.rtf (17.2 KB)

Me too. SpamSieve ran well under Sonoma for a couple of days. It’s frozen dead now for past 5 days. Force Quit > Restart >immediately Freezes. But it did work for a while. Now? Just a spinning beachball.

I’m waiting for it to crash again, then I will send the information you need. Since my initial post I reset it, it doesn’t seem to happen until I get a bunch of spam - or it may be a specific one, I don’t know. I manually went in and deleted all of them so I could keep it running before I read this post.

Thanks. I was able to reproduce the problem. It seems to be a Sonoma-specific Swift Regex bug that’s triggered by matching the regular expression \bV..AGRA\b against the message subject 𝐀𝐋𝐄𝐑𝐓 ⛔️:Someone tried to log into your accounts⛔️ Your McAfee Antivirus Software subscription has reached its expiration date on Sat, 07 Oct 2023 18:42:05 +0000.

It’s a very short string, so this seems like some sort of infinite loop bug rather than a case of poor performance. I’m posting the relevant part of the sample here in case someone else is Googling for an issue like this:

2354 Regex._firstMatch(_:in:)  (in libswift_StringProcessing.dylib) + 230  [0x7ffc23002f66]
  2354 Regex._firstMatch(_:subjectBounds:searchBounds:)  (in libswift_StringProcessing.dylib) + 219  [0x7ffc22fcbd5b]
    2354 Executor.firstMatch<A>(_:subjectBounds:searchBounds:graphemeSemantic:)  (in libswift_StringProcessing.dylib) + 696  [0x7ffc22ff0a18]
      2354 Executor._match<A>(_:from:using:)  (in libswift_StringProcessing.dylib) + 65  [0x7ffc22ff1031]
        2354 Processor.cycle()  (in libswift_StringProcessing.dylib) + 1452  [0x7ffc22fe6d5c]
          2354 Processor.builtinAssert(by:)  (in libswift_StringProcessing.dylib) + 563  [0x7ffc22fe8e33]
            2315 String.isOnWordBoundary(at:using:_:)  (in libswift_StringProcessing.dylib) + 299  [0x7ffc22fe951b]
            ! 1168 String._wordIndex(after:)  (in libswiftCore.dylib) + 105  [0x7ff81eb642d9]
            ! : 542 _StringGuts.previousWordIndex(endingAt:)  (in libswiftCore.dylib) + 491  [0x7ff81eb4ab2b]
            ! : | 524 specialized Unicode._WordBreakProperty.init(from:)  (in libswiftCore.dylib) + 83  [0x7ff81ec3fee3]
            ! : | + 524 _swift_stdlib_getWordBreakProperty  (in libswiftCore.dylib) + 74,84,...  [0x7ff81ed424fa,0x7ff81ed42504,...]
            ! : | 18 specialized Unicode._WordBreakProperty.init(from:)  (in libswiftCore.dylib) + 107,40,...  [0x7ff81ec3fefb,0x7ff81ec3feb8,...]
            ! : 506 _StringGuts.previousWordIndex(endingAt:)  (in libswiftCore.dylib) + 480  [0x7ff81eb4ab20]
            ! : | 473 specialized Unicode._WordBreakProperty.init(from:)  (in libswiftCore.dylib) + 83  [0x7ff81ec3fee3]
            ! : | + 473 _swift_stdlib_getWordBreakProperty  (in libswiftCore.dylib) + 74,60,...  [0x7ff81ed424fa,0x7ff81ed424ec,...]
            ! : | 33 specialized Unicode._WordBreakProperty.init(from:)  (in libswiftCore.dylib) + 30,107,...  [0x7ff81ec3feae,0x7ff81ec3fefb,...]
            ! : 76 _StringGuts.previousWordIndex(endingAt:)  (in libswiftCore.dylib) + 486,514,...  [0x7ff81eb4ab26,0x7ff81eb4ab42,...]
            ! : 24 _StringGuts.previousWordIndex(endingAt:)  (in libswiftCore.dylib) + 390  [0x7ff81eb4aac6]
            ! : | 24 specialized _StringGuts.decidePostFormatBackward(between:and:with:)  (in libswiftCore.dylib) + 35,4,...  [0x7ff81ec3ff23,0x7f
            ! : 19 _StringGuts.previousWordIndex(endingAt:)  (in libswiftCore.dylib) + 458  [0x7ff81eb4ab0a]
            ! : | 19 _decodeScalar(_:startingAt:)  (in libswiftCore.dylib) + 8,59,...  [0x7ff81eabf348,0x7ff81eabf37b,...]
            ! : 1 _StringGuts.previousWordIndex(endingAt:)  (in libswiftCore.dylib) + 106  [0x7ff81eb4a9aa]
            ! :   1 _decodeScalar(_:startingAt:)  (in libswiftCore.dylib) + 0  [0x7ff81eabf340]
            ! 899 String._wordIndex(after:)  (in libswiftCore.dylib) + 154  [0x7ff81eb6430a]

You should be able to avoid the crash by going to SpamSieve’s Blocklist window, searching for \\b (you need the extra backslash to escape it, since backslash is normally used for escaping search wildcards), and clicking to disable both Viagra rules.

SpamSieve 3.0.1 will include a workaround for this, at which point you can re-enable those rules.

Going forward, if you see a hang for some other reason such that you have to force quit, please:

  1. Before force quitting, please record a sample from SpamSieve.
  2. After force quitting, open the Log window, find the log entry that says Message Data Triggered Crash, and drag it from the list to Finder. This will export it as a .eml file with the exact data that SpamSieve received from the mail client.
  3. Save a diagnostic report.
  4. Send the sample report, .eml file, and diagnostic report to

I’ve worked around this bug in SpamSieve 3.0.1b1. It’s also reported to Apple as FB13249322.

Sonoma 14.0, SpamSieve 3.0
Magically, mysteriously, this morning, SpamSieve has not frozen solid. It’s been working very well. That wasn’t the case over the past 5 days.

Two days later, SpamSieve is frozen again. Force Quit. Relaunch SpamSieve. Boom! Spam cleaned up!

Please update to SpamSieve 3.0.1b1.

SpamSieve 3.0.2 working like a champ!

1 Like

I’m also having frequent lockups in Mail on Sonoma.
SpamSieve 3.0.2, Sonoma 14.1.2, Mac Studio.

I’m attaching logs.
Sample of Mail.txt (442.2 KB)

Thanks for the report. It looks like Mail is getting stuck fully downloading the messages, possibly a bug with it trying to do that at the same time it’s sending messages to the Mail extension to be processed. It may help to turn off the SpamSieve Mail extension in Mail ‣ Settings ‣ Extensions. This is OK to do because SpamSieve will fall back on filtering the messages using a different method. (You should leave the Mail extension enabled within SpamSieve’s settings.)

There are some changes in SpamSieve 3.0.3b1 that should hopefully work around the Mail bug that causes this lock up automatically.