Closed core-code closed 2 months ago
Yeah need more information. To disassemble or symbolicate it, ideally you'd have the base/image address of Sparkle in the report and if it's x86_64 or arm64. Is it using Sparkle 2.6.0 and is it using a pre-built binary version? It's not obvious where +[NSString stringWithFormat:] is being called and less obvious of where it's called where the format is nil. Potentially there is also inlining involved.
i think we used the stock 2.6 binary, just re-signed which shouldn't change the offsets, but was unable to recover the image address
we can just close this until we receive more reports of this, hopefully with line numbers
also SPUSystemNeedsAuthorizationAccessForBundlePath() does not even call stringWithFormat: so this looks too fishy to continue investigating at this point
Yeah, you really need the base/image address of Sparkle at minimum so you can compute the slide. If this is not a full crash log report you won't have that.
Actually looking at the last backtrace item where we do have an offset
5 Sparkle 0x000000010283be78 Sparkle + 15992
Issue occurs somewhere in -[SPUBasicUpdateDriver didNotFindUpdateWithLatestAppcastItem:hostToLatestAppcastItemComparisonResult:background:]
.
I think this issue is the same as the one https://github.com/sparkle-project/Sparkle/pull/2533 fixes (fixes #2524) (fix went in 2.6.1).
SPUSystemNeedsAuthorizationAccessForBundlePath
was indeed a bogus lead.
i am unsure if that could have been the case. we have a protection against the evil "app has been moved" situation and immediately throw up an alert offering to relaunch the app.
in any case, going to update the framework to the latest version. thanks.
In any case localization is the only case where a non-static string should be passed as the format string and that PR change guards against a nil value.
we got a crash report from a user, unfortunately it is without line numbers. but i could fire up a disassembler if it helps