-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
STATUS_STACK_BUFFER_OVERRUN return code when running with dynamic linking using rust-lld on Windows 11 #2921
Comments
Just encountered this error on Win11. Don't think adding nochecks to anything is a solution since the error indicates the compiled code runs into a buffer overflow possibly overwriting return address. |
Actually according to this, the response code is more of a misnomer. |
When compiling with
|
You will either need to add |
@bjorn3 now, I don't get errors of missing dependencies anymore. But my executable still crashes with an exception in the middle of some disassembled code. Thanks for your efforts, though. |
If anyone comes across this later, I am running on the nightly toolchain and am able to build and run with the dynamic feature enabled by only dropping the following into my
|
Dynamic by itself was never an issue for me, only coupled with the lld linker. |
Here's a quick reminder that this issue still persits in Bevy 0.7 |
It still persists with |
I made a clean Windows 10 install and everything worked fine following the official bevy tutorial, but after upgrading to Windows 11, I got the |
I tried to do what @aka-bash0r did and copied the required DLLs around (I copied the debug version of bevy_dylib-.dll from my directory and the Rust std library DLL from Opening it in Visual Studio 2022 CE, it stops in some C/C++ glue (?) that, from what I've understood (... but I might be wrong) loads the instance of bevy_dylib.dll, as possibly described by the stack call window entry:
After that (point 0) there are 2 other calls (1 and 2) on the stack, without source since it's MS code: it calls into XInput.dll (that should be DirectX's DirectInput implementation) for 2 stack frames, then crashes:
Checking the assembly code since there aren't sources available from Microsoft, the crash happens after a 00007FF87E7F7A3C push rbx
00007FF87E7F7A3E sub rsp,40h
00007FF87E7F7A42 mov rax,qword ptr [__security_cookie (07FF87E7FC068h)]
00007FF87E7F7A49 xor rax,rsp
00007FF87E7F7A4C mov qword ptr [rsp+30h],rax
00007FF87E7F7A51 xor edx,edx
00007FF87E7F7A53 lea rcx,[g_VidPids (07FF87E7FC650h)]
00007FF87E7F7A5A lea r8d,[rdx+40h]
00007FF87E7F7A5E call memset (07FF87E7F82A9h)
00007FF87E7F7A63 cmp qword ptr [WPP_GLOBAL_Control+28h (07FF87E7FC038h)],0
00007FF87E7F7A6B mov rax,qword ptr [WPP_GLOBAL_Control+10h (07FF87E7FC020h)]
00007FF87E7F7A72 movups xmm0,xmmword ptr [rax-10h]
00007FF87E7F7A76 movdqu xmmword ptr [rsp+20h],xmm0
00007FF87E7F7A7C je RegisterUtcEventProvider+49h (07FF87E7F7A85h)
00007FF87E7F7A7E mov ecx,5
00007FF87E7F7A83 int 29h The debugger's output windows shows (as could be expected, given the int 29h call with 5): HOWEVER: this is at least a bit different than what happens when run with cargo, since without debugger I don't get the exception printed out, so the reason might be different (some other configuration I'd need to perform manually). QUESTION: where can I read how a IDEAS: can we try to disable XInput somehow? Check if there are newer crates/bugs filed in... gilrs? gilrs-core? It might also be in other types of input however (touch?) or unrelated functions inside the DLL (from https://docs.rs/rusty-xinput/1.2.0/src/rusty_xinput/lib.rs.html we can see it has functions like XInputGetBatteryInformationFunc or XInputGetAudioDeviceIdsFunc ...) |
Knowing more details about what was the problem, I tried to search for people with similar issues on Google and... I first found a post on the official Visual Studio support forum from somebody that had the exact same problem, crash in XInput1_4.dll when compiling an old project using clang-cl under Windows 11. See "Clang-cl tool chain results in dll loading issues for Xinput.lib". The interesting part of that post is that the author said he was creating an "input library" for XInput that was working on previous versions of XInput/Windows/VSC++ clang, and that apparently defining a function called DllMain somewhere in that input library will avoid the crash (probably by overshadowing the DllMain function inside XInput1_4.dll?). Is any of the input crates doing that, or using an 'external' input library for XInput? Then I continued searching for people having trouble with XInput1_4.dll and I didn't find much other than people recommending to download it from fishy websites and copy it in Windows\System32... HOWEVER, one of the posts, about Chivalry 2, was a bit different: it recommended renaming XInput1_3.dll to XInput1_4.dll and that, if you did have an XInput1_4.dll and the game still didn't work, you could simply delete/rename the file and copy the 1_3 version with the same name as the 1_4 version. I tried and guess what? Program using the dynamic feature are now working! 🥳 The XInput1_4.dll file was NOT locked on my system, meaning that none of the programs normally running in my system was using it (so all the bunch of crap from Asus to manage the strange hardware is ok). Steam and Epic clients are ok. After renaming the files, everything is still Ok, including Unreal 5 and Blender and a few of the games I was able to try. Unfortunately they're a bit old so they might use older versions of XInput anyway. Now I'm finally able to compile a small change in < 4 seconds instead of 90+ and this will definitely help me in learning Bevy and experimenting with my game learning project 😄 |
What a great find! I can confirm the problem is indeed with
So if one can also disable Sadly I wasn't able to find which crate is requiring |
The winapi crate depends on XInput1_4.dll if the xinput feature is enabled. According to
|
Same, first works: (UPD: sometimes it fails too!)
second, fails:
What are the benefits of lld though❓ |
Lld is much faster than most linkers. |
Also rust-lld doesn't choke if you have more than 65535 symbols (something that happens easily with Rust, apparently) like Microsoft's linker does, see #1110 P.S. |
I was able to test disabling The "funny Windows thing of today" is that both Steam and the Nvidia share assistant decided they now need to use |
@alice-i-cecile do you think it's worth adding a warning on Bevy Book - Setup about using It seems disabling This only applies to development process using |
I'm reluctant to encourage that, especially for beginner users. However this investigation is incredibly valuable; we should continue reducing the problem and attempt to fix it upstream in gilrs. |
I made a test project, but I don't know where to open issue. Since this is related to |
Yes please, upstream for the compiler team is the place for this. Make sure to link this thread. That's a great minimal example, thanks a ton. |
Based on @RobertoMaurizzi's findings that
The drawback of this is you will need to repeat this process any time you run This works, because windows DLL loader searches for DLLs in the executable directory first by default. That way you can effectively replace any system DLL that a program tries to load. Fun fact: this is often used by various game mod loaders in order to hook into the game at startup without having to patch any executable file. One way of doing it is to place fake system DLL in your game directory (often xinput, thanks to it having small api surface), that passes all real function calls to the real system DLL, but additionally injects actual mod loader DLL to the game process by calling |
According to |
Opened an issue on gilrs https://gitlab.com/gilrs-project/gilrs/-/issues/127 assuming they are open to it, and no one beats me to it, I should have time to work on it Friday. |
That would be massively appreciated; better gamepad support on Windows + dynamic linking on Windows would both be incredible. |
Poking around on the GitLab repo, it looks like that PR has been merged and released as of 0.10.0 or 0.10.1 - might be worth another look? |
yup: #6558 |
I just tried this on bevy/main since that just got merged and this is now working for me while using the Note that you do still have to make sure to add this to your cargo.toml
Without that I was getting |
Hey, just wanted to let you know that it's now working for me with bevy 9.1, rust-lld and rustc 1.66. |
Closing this out! Feel free to reopen if y'all can reproduce. |
So I was chasing the same issue for a while, and I managed to get to the bottom of it. Please see: llvm/llvm-project#82050 |
Bevy version
0.5 and main ( 07ed1d0 )
Operating system & version
Win 11 (day1 release - 21H2)
What you did
Running cargo run a minimal hello.world bevy app with dynamic linking using rust-lld on Win11.
config.toml
What you expected to happen
The app runs with dynamic linking
What actually happened
The process ends immediately with
Additional information
Either not using or rust-lld works.
This compiler flag seems that it could be related, but adding
-Ccontrol-flow-guard=nochecks
to config.toml did not help.Also possibly relevant:
MS Docs on the MSVC flag /GS
MS Docs on Control Flow Guard
The text was updated successfully, but these errors were encountered: