-
-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Occasional abort trap 6 error when signing application bundles #82
Comments
So I managed to reproduce the crash by forking your repo, setting all the certs up, and ssh-ing into the runner. I recovered a bunch of information. First of all, this seems to be either a double free or otherwise a case of freeing a pointer that wasn't malloc'd (memory corruption?), according to this output I found while running rcodesign directly in a terminal in the CI:
Running the same command on the same bundle with the same certs on my local mac does not trigger the crash. So I guess there's something different between the CI and my local environments. Of course, there's a lot of subtle differences (for instance, I'm using macOS 13.3.1 on an M1 mac, the runner is on 12.2.6 on an x86_64 VM). Here's the unsigned bundle: staged.zip The crash report summary
The crash.ips file
|
Another interesting thing: I ran In the meantime, @ofek you may be able to self-build apple-codesign and use that instead of the release to fix your immediate issue. |
Very interesting, I will try that now thanks! BTW how did you SSH into the runner? I didn't know that was possible |
Building anew does indeed fix the issue, thank you! I will leave this open until there is a new release however since building adds at least 9 minutes to CI. |
Using tmate, see this commit . It uses mxschmitt/action-tmate which takes care of installing tmate, starting the tmate session, and giving the ssh command in the job log output. Very convenient to debug these kind of issues ^^. |
Thanks for grabbing the crash info, @roblabla! The crashing stack has all the hallmarks of a memory corruption bug. Crashing code is in My knee jerk is this must be a binary portability issue. Mach-O binary built with newer macOS SDK crashing when run on older macOS machine. This type of thing is known to happen. But it shouldn't happen and most often points to a bug in the macOS SDK, potentially a bug in the clang toolchain in it. Could you please try grabbing an |
Yes that works I tried multiple times pypa/hatch#900 |
While I'd like to understand how this crashed, I haven't seen any other reports of rcodesign crashing. I suspect this has to do with a portable Mach-O binary issue. I'm going to close this due to lack of actionable details. I should have a new release out shortly. |
By occasional I mean basically half of the time. Restarting the job that signs the binaries has no effect on this step for some reason and I must restart the entire pipeline, building from scratch.
https://github.com/pypa/hatch/actions/runs/5301640159/jobs/9596106008
The text was updated successfully, but these errors were encountered: