Closed kdrag0n closed 1 year ago
Do you have the full crash log files or at least the base address of Sparkle in the report (assuming you are using one of our pre-built distributions of Sparkle). The backtrace doesn't make a whole lot of sense, although the assert does seem convincing.
In any case, moving or mutating the app bundle while it's moving is not really supported. Even if I could simulate reproducing this issue (which I have not been able to) and make it fail gracefully, any other point of your app or Sparkle could fail badly later.
More interesting to figure out is why this is happening and then how to address the root problem, but I suspect that will be difficult.
I guess it doesn't hurt to make this fail gracefully, why not.
Right, I'm not sure how to reproduce it either but in the past I've seen Bundle.path(forAuxiliaryExecutable:) return nil
in cases like this, so I started using "\(Bundle.main.bundlePath)/Contents/MacOS/\(name)"
instead to fix the issue in my app's code.
I'm using SwiftPM so I think it's built from source, but here are the raw addresses:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0xfff00d0511f2 0xfff00d049000 + 10
1 libsystem_c.dylib 0xfff00ce96b44 0xfff00ce17000 + 122
2 libsystem_c.dylib 0xfff00ce95e5d 0xfff00ce17000 + 313
3 Sparkle 0x10884c157 0x10881a000 + 8713
4 Sparkle 0x108841aff 0x10881a000 + 4437842687
5 Sparkle 0x108841ffe 0x10881a000 + 1269
6 libdispatch.dylib 0xfff00cd82d90 0xfff00cd81000 + 11
7 libdispatch.dylib 0xfff00cd84032 0xfff00cd81000 + 7
8 libdispatch.dylib 0xfff00cd90fce 0xfff00cd81000 + 953
9 libdispatch.dylib 0xfff00cd90c06 0xfff00cd81000 + 30
10 CoreFoundation 0xfff00d243235 0xfff00d187000 + 9
11 CoreFoundation 0xfff00d20306f 0xfff00d187000 + 2452
12 CoreFoundation 0xfff00d202071 0xfff00d187000 + 560
13 HIToolbox 0xfff02071ffcc 0xfff0206f1000 + 291
14 HIToolbox 0xfff02071fddd 0xfff0206f1000 + 656
15 HIToolbox 0xfff02071fb37 0xfff0206f1000 + 63
16 AppKit 0xfff01336379f 0xfff013325000 + 857
17 AppKit 0xfff013362649 0xfff013325000 + 1213
18 AppKit 0xfff013354cb7 0xfff013325000 + 585
19 AppKit 0xfff013328ed1 0xfff013325000 + 816
20 SwiftUI 0xfff221916cba 0xfff221891000 + 13712
21 SwiftUI 0xfff22294ff43 0xfff221891000 + 27163
22 SwiftUI 0xfff22226c3ae 0xfff221891000 + 47121
Binary Images:
0x10881a000 - 0x10885dfff Sparkle x86 <5a4580eea89034fe89d1b9a730e89621> /Applications/OrbStack.app/Contents/Frameworks/Sparkle.framework/Versions/B/Sparkle
Let me know if I should try to symbolicate it manually.
I'm using SwiftPM so I think it's built from source
Actually we provide a prebuilt binary distribution.
The offsets in that backtrace are kind of sad again :(.
In any case, I'm just going to address this by failing more gracefully. I'm not too convinced to work around Bundle.path(forAuxiliaryExecutable:)
not being "reliable". NSBundle doesn't support bundles moving around, though.
Makes sense, thanks for the quick fix/workaround!
Summary
I saw this rare crash in the wild:
Another case:
I suspect that this happens when people delete the app bundle while it's running (perhaps with
rm -rf
) and later try to apply an update.Potential Fix
It might be worth showing an error alert instead of crashing in this case.
Version
v2.4.2