Repository navigation
Completion dialog renders oversized/empty and crashes on interaction (NSBitSet.m:96) #183
Description
Quick disclaimer: I had help from Claude Opus formulating this issue, I hope that's fine with you.
Version: RsyncUI 3.0.5 (build 208)
macOS: 27.0 (26A428), MacBookAir10,1 (M1), dual display
Description
When a synchronize job finishes, a dialog appears over the main window. It is rendered empty and far larger than the window — it extends past the window bounds, so any content below the visible area cannot be read. The app then crashes as soon as I interact with it (e.g. pressing Enter). Here is a screenshot:
Reproducible on every run. Happens whether the job is started from the GUI or via a rsyncuiapp://loadprofileandestimate deep link.
The crash occurs only after interacting with the dialog.
Result
After the crash, "Last Sync" for the task is unchanged (still showing the previous run), so the completion write-back never happens.
Exception
Assertion failure in NSBitSet.m:96
NSInternalInconsistencyException
EXC_BREAKPOINT (SIGTRAP) via +[NSApplication _crashOnException:]
Process ran 19:14:14 → 19:38:05 (~24 min).
procRole: Background (app was not frontmost; I was working on another display).
Backtrace (abridged)
objc_exception_throw
_NSBitSetResize.cold.1
NSBitSetAddIndex
NSISLinExpEnumerateVars
-[NSISEngine tryAddingDirectly:]
-[NSLayoutConstraint _addToEngine:mutuallyExclusiveConstraints:]
NSViewSetAutoresizingConstraints
-[NSView updateConstraints]
-[NSWindow updateConstraintsIfNeeded]
CA::Transaction::commit()
No RsyncUI frames appear apart from the app entry point.
Notes
The empty dialog plus the missing "Last Sync" update suggest the completion view is presented before (or without) its data, and that its layout ends up in an inconsistent state. An Auto Layout assertion of this kind typically points to layout-affecting state being mutated off the main thread — worth checking that the job-completion path hops to @mainactor before updating anything the views observe.
Impact
Data itself seems unaffected; the crash happens after the transfer, in the UI layer. But the run is not recorded, and the dialog is unusable.
Activity
rsyncOSX commentedon Sep 23, 2026
I will look more into it tomorrow. Rsync might have discovered som error, this is how an error is announced and the task is terminated- no logging...
rsyncOSX commentedon Sep 24, 2026
I suggest you try to verify the task in Tasks meny and choose verify. See what happens, any error in the output from rsync will most likely show up there.
daLuiz commentedon Sep 24, 2026
Thanks for the hint that the dialog announces an rsync error — that led to the cause.
Verify showed no errors, which makes sense since it's a dry run and never applies anything. But it did show 529,115 output rows across ~760k files, almost all itemized as permission changes (
.f...p.....).My destination is a shared folder on a Synology NAS, where chmod might not stick. So on every real run rsync presumably failed to set permissions on most files and exited with an error, which triggered the error dialog.
With
--no-perms, the verify output dropped from 529,115 rows to 412, and the real sync completed normally — no error dialog, "Last Sync" updated.So the root cause was on my side. But the dialog probably shouldn't crash on very large error output: it rendered empty and oversized, and interacting with it triggered the Auto Layout assertion (_NSBitSetResize). Truncating the content (e.g. first N lines plus a pointer to the full log) or using a scrollable view might be worth considering. Synology destinations with ACLs are common, so others may run into the same thing.
Worth noting: this setup worked fine until recently. The last successful run was on Sep 8, the first failure on Sep 23. I didn't change anything on the Synology side. In between, two things changed on my Mac:
So either rsync started reporting the failed permission updates as an error, or RsyncUI started treating that exit status differently. Either way, the permissions were most likely never applied on this destination — the difference is that it now surfaces as an error.
rsyncOSX commentedon Sep 24, 2026
Thanks for reporting, I suspect RsyncUI discovered the error late in the output causing the overflow in output. You may switch off checking for error in the output. Anyway, I will add this issue to the todo list for next maintenance release (don't know when to be released). There was no updates in RsyncUI regarding the discover of error from 3.0.3 -> 3.0.5. But the fix is to handle the output and try to only display the line causing the error.. Closing the issue now, will make a fix for it in the next release..
rsyncOSX commentedon Sep 30, 2026
Sorry for long wait, but I have fixed the issue. Do you care to test it, I have just created a branch version-3.0.6 and I may compile a signed and notarized dmg for you to test.
daLuiz commentedon Sep 30, 2026
If you want, sure I can test it! but I am not in a hurry, the —no-perms fixed it for me.
rsyncOSX commentedon Sep 30, 2026
Great, just uploaded a "version-3.0.6 rc" as a prerelease. If check for error is on and the word "error" is discovered in output, RsyncUI cuts off all output except the 10 last lines.
The most important is to verify the fix does not break a normal use of RsyncUI. I am testing it myself. The fix itself is only a few lines of code.
daLuiz commentedon Sep 30, 2026
so, i removed the
--no-permsto provoke the error again, and I can report some progress:--no-permsagain, but to my surprise I got the same result, the sync job just didn't complete, no error messages.--no-permsagain to provoke the error again, and ran dedicated "Estimate" & "Syncronize" actions one after the other. Still no crash, but also still no completed sync job again, without any error messages.In conclusion: The original crash from the message box is gone, but there seems to be a regression with the "Estimate & Sync" action. Also I would wish for some kind of truncated or scrollable error message window, to give the user an indication that the job didn't complete and ideally the error message.
daLuiz commentedon Sep 30, 2026
after some more testing "Estimate & Sync" does now work in 3.0.6 with
--no-perms, at least for small changes in the dataset. I can't reproduce the previous behaviour now, but it was a larger delta in the dataset when it didn't work previously.. weird.rsyncOSX commentedon Sep 30, 2026
Great, thanks for testing. I will add a line that task is canceled, that is files until error is discovered are transferred but files after that and logging are not done. I will do some more testing myself. The actual discover of the error is done in the package RsyncProcessStreaming and the handling of the error is a closure which are feed into the package. There are no other changes other than in the closure. So all other functions like Estimate & Sync should work as normal.