Crashes on Apple Silicon #2033
Comments
|
Yes, exactly. You are nesting uc_emu_start, which could potentially leads to this crash. Temporary workaround is not calling uc_emu_start in any callbacks. |
|
Thanks, I understand. Do you have any plans to solve this problem in the future? Additionally, there may be problem with the dylib provided in the wheel, as it cannot even run the most basic samples in my environment. |
This is easy to solve if you could provide a smaller reproduction. Usually just we forget to save/restore JIT status before entering JIT regions.
I have no idea about this. The building environment should be the same or there might be Github Action bugs. Again, we need a reproduction to locate this issue. But we will soon test the shipped wheel before distribution in #2026 |
|
I will find a way to simply reproduce it. |
The second issue will occur to |
Full script? |
|
|
That works on my mbp. Are you on dev branch and what error do you get? |
|
I just installed unicorn using pip in a project that only has sample_arm64. The crash log is: |
|
If I use locally compiled dylib, this problem would not occur. |
I have no idea why the built dynamic libraries by Github Action is failed but #2026 will surely address this by testing the wheels before uploading to pypi. This will be shipped along with 2.1.2, probably before the end of this month. Locally testing shows that probably the JIT state is not switched but no idea why. |
|
I have found a solution to the first problem, remove a judgment condition in => After this, my program can work normally. Meanwhile, I noticed that this judgment condition was specifically added by you in the commit. |
|
This would fail other cases. I remember I added corresponding cases and you can run ctest to check. Generally, the root cause is that we allow users to re-entry the JIT area and the area is shared all together. It’s hard to determine the correct state given current design. |
|
ctest all passed. There are two judgment conditions in your commit, removing the condition in |
|
I can't remember the exact context of this commit and I will have a check. By the way, could have a try with the wheel from here: https://github.com/unicorn-engine/unicorn/actions/runs/11385747394 (note artifacts below) |
Still crashing. Is my system version or CPU is too new (14.2 + M3 Pro) ? |
That's weird, these wheels pass all simple tests (including the sample you mentioned) |
Sorry, it's been a while. I extracted the reproduction code. |
|
I have another similar issue (simulating x86 programs on m3pro) terminal output: report: |
Your case might be the same as the second problem I mentioned above. The wheel on PyPI is not available, and building the wheel locally should resolve this problem. |
Could you possibly take a look at this? @wtdcode |
|
I found a way to reproduce this. It crashes pretty early when initializing the Unicorn instance. Unfortunately, there is no debug symbols for the released binary so I need a bit more time to investigate. |
|
@sledgeh4w Could you test the artifact from a more recent building: https://github.com/unicorn-engine/unicorn/actions/runs/12211818265 ? I tested the cibw-wheels-macos-latest-7-py38 downloaded from this run. It works well while the artifact from older runs doesn't work indeed. I believe that we should blame Github Action for the crash or @Antelox work fixes this. Either way, please have a try! By further inspecting the artifact that doesn't work, the JIT state is not properly saved and restored. The relevant functions are compiled as no-ops as x64 macOS. |
Unfortunately, it has not been resolved. |
This code is used to reproduce crashes during nesting call |
|
The root cause is the Github Action not allowing access to SPRR registers. I submitted an issue: actions/runner-images#11127 I will disable the distribution of pre-built wheels for arm64 in the next release. At this moment, users need to build unicorn locally. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I use Unicorn to emulate iOS executable file. It works normally on Windows, Linux, and macOS x86, but crashes on Apple Silicon (Not all scenes will crash, but they can be stably reproduced).
The environment I am using is macOS 14.2 with M3 pro.
The error message is:
The crash log is:
I noticed this crash log is similar to stackoverflow, so I guess it may also be due to the same reason.
Reproduce this issue:
The text was updated successfully, but these errors were encountered: