-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
illegal instruction crash in rust 1.78 #126195
Comments
@rustbot label -needs-triage +O-windows +A-linkage |
I doubt this is a linkage issue as |
Hmmm.... could this be that the missing DLL causes this issue? Like trying to jump to address 0x0? Here's what I know -
I am now build a new binary with rust 1.77.2. Will distribute it and report back if it fixed the issue or not |
If you can use an affected machine directly then you could try using windbg to see what instruction is causing this. |
@ChrisDenton I'm not that familiar with windbg and native code debugging, but if you can provide instructions, I'll see if my user agrees to try it :-) |
Ah, that might be more complicated. Can you get a backtrace from them? And their CPU information, if possible? If they did want to have a go at windbg, it can be downloaded from here and there's a tutorial. However, it should be relatively simple in this case. You just run windbg and, from the file menu, click "Launch Executable" then find the exe to run. After that you just click the green "Go" button and when the exe crashes it should highlight the offending instruction in yellow. |
A quick update - I heard back from the user and it seems downgrading to rust 1.77.2 fixed the issue. |
Here's the output from windbg. Hope it helps narrow it down :-) |
|
can you guide me on how to figure this out? This exe is compiled using x86_64-pc-windows-gnu with profile production
|
Regarding cpu info - this is the cpu on the machine where it crashed 13th Gen Intel(R) Core(TM) i9-13950HX 2.20 GHz |
@bjorn3 @ChrisDenton I tried getting more info about where the process was failing. With a debug build the problem did not reproduce. I'm not that familiar with windbg and native code debugging on windows. If you guys can advise on how to understand which function is failing it would be great (like generating debug symbols during build, that windbg understands). I'm compiling the exe file with x86_64-pc-windows-gnu, not sure if it matters or not. |
Would setting |
Hmmm.... I'm cross compiling from linux, and not using msvc. Do I have to compile using msvc? |
Are you using the x86_64-pc-windows-gnu target? If so you have to use gdb instead of windbg as debugger. MinGW and MSVC use different debuginfo formats with gdb only supporting the MinGW format and windbg and most other Windows debuggers only supporting the MSVC format. |
OK, I'll try to compile with msvc. |
As you have already discovered, Are you able to share the code or the binary with full debuginfo? Regarding PDB, I don’t know how well it works, but at least Git for Windows uses cv2pdb on binaries created with GNU tools, so it probably should be enough to load it into WinDbg or Visual Studio. |
@mati865 I'm afraid I cannot share the full code. Good to know I can translate gnu debug info to pdb. Right now I went the msvc route. I'm waiting to hear from the user if the issue reproduced with an msvc build. Thanks |
The issue reproduced with msvc compilation. Here's the windbg output. If I understand correctly - this is the failing function - https://github.com/tabnine/notify/blob/e63a681be7851e1a9506d533b17af1f374e4fdba/notify/src/windows.rs#L110 This is the stacktrace windbg reports Any suggestions? |
Great! That function is still on the large side though. Can you disassemble this function and post the output somewhere? You should be able to do this yourself based on the executable you gave your user. According to stackoverflow loading the executable in windbg and running |
Here it is
|
That prints only part of the function and misses the part where it crashes by a big margin. |
Is there a way for me to print out the entire function? |
I did Here is the output. Let me know if that helps: https://gist.github.com/amircodota/9b1c59c0c0770e2c2da1bf43071a9aaf |
For reference, this is the same function in rust 1.77.2 https://gist.github.com/amircodota/17a5c098e571d29d290793b86ab752a8 |
The crashing instruction is Try replacing https://github.com/tabnine/notify/blob/e63a681be7851e1a9506d533b17af1f374e4fdba/notify/src/windows.rs#L307 with As for why you can't locally reproduce it, this code seems to run only when tl;dr: There is UB in the notify crate. It may still be the case that fixing this UB doesn't fix the observed behavior though. |
Thank you very much for the thorough explanation. I'll try it out and let you know |
A quick update - I could not get the original user to try it out, but I was able to reproduce locally with some effort, and I verified that the suggested fix indeed solves the "illegal instruction" crash. If anyone's interested - this is the fix Closing this issue. Really appreciate all the help I got from everyone :-) |
See more details here - rust-lang/rust#126195
I'll add some noise to say: Thanks for debugging this mess, especially to bjorn3. |
Since rust 1.78, windows produced binaries have a dependency on the
api-ms-win-core-synch-l1-2-0.dll
which seems to be missing on some installations of windows 10 and 11.We've had reports from users of our binary that our latest version fails with error
0xc000001d
The text was updated successfully, but these errors were encountered: