Unable to run bevy application via VSCode debug UI

[alexmadeathing]

Bevy version

0.5.0

Operating system & version

Windows 10 Pro Build 19043.1110

What you did

• Followed first time set up using: https://bevyengine.org/learn/book/getting-started/setup/
• Set rustflags = ["-Zshare-generics=off"] in .cargo/config.toml as per the following issue:
  Win10: Trying to link Bevy dynamically results in the error STATUS_ENTRYPOINT_NOT_FOUND #1126 (comment)
• Build via terminal command: cargo build
• Create the following .vscode/launch.config:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(Windows) Launch",
            "type": "cppvsdbg",
            "request": "launch",
            "program": "${workspaceFolder}/target/debug/game-test.exe", // Adjust exe name appropriately on your machine
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "console": "internalConsole"
        }
    ],
}

• Create the following src/main.rs:

use bevy::prelude::*; // The presence of this line triggers the issue

fn main() {
    println!("hello world!");
}

• Attempt to run using the VSCode Debugger UI, selecting the launch configuration we created above

What you expected to happen

Starting the executable via cppvsdbg debugger in VSCode should complete successfully with no error.

What actually happened

The following error is reported in Debug Console:
The program '[10184] game-test.exe' has exited with code -1073741515 (0xc0000135).

It seems like the application terminates early due to missing modules.

I opened Process Monitor whilst running the application via VSCode debug to see what binaries were getting linked into the application. It seems that the following file is missing under all search paths: std-92c1680604aea3a5.dll.

So I ran again, this time using cargo run, which I know works fine. This time, the missing dll was correctly found at:
<path\to\user>\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\std-92c1680604aea3a5.dll.

So this suggests that my .vscode/launch.json is missing some vital pathing to the toolchain target std lib.

My rust and cargo knowledge is extremely limited, as is my vscode knowledge to be fair. If I were to guess, I would say that the launch configuration is not providing enough pathing information to the loading binary, whereas cargo run does provide this. So I think there may be a missing step in the Bevy docs to get debugging working - I'm just not sure what it is yet.

Anyone else able to repro this?

Additional information

Running the application via cargo run works fine - in fact, it should be noted that I can get started learning Bevy using this method, however, I'd very much like to get debugging working.

Manually running the executable from CMD or by double clicking the exe yields the following error:

Manually running from the VSCode terminal yields nothing (actually I think maybe the stdout is routed somewhere weird, so best not to read too much into that).

[alexmadeathing]

I'm also not entirely sure that this is a Bevy bug, but I'd like some of you guys to try and repro it before I take it broader since this is the only way I know how to repro the issue - other rust applications can be debugged without issue. Maybe creating an app that links with something in the rust target would cause the issue too? Anyone know what is in that std*.dll binary? Is it just a rust ABI for the std crt?

[alexmadeathing]

Adding a zip containing the minimal example:
game-test.zip

[bjorn3]

Did you enable the dynamic cargo feature of bevy? If so you will need to modify the path to include the bin dir of the rustc sysroot (std-*.dll should be here) and the target/debug dir (bevy_dynamic.dll should be here) Cargo nornally does this automatically for you when doing cargo run.

[alexmadeathing]

Did you enable the dynamic cargo feature of bevy?

Yes, my Cargo.toml includes Bevy using the following:
bevy= { version = "0.5.0", features = ["dynamic"] }

you will need to modify the path to include the bin dir of the rustc sysroot

Yeah, the std-*.dll binary is in <path/to/user>\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\bin, so that would be the path I need to add.

I'm just not sure how I do that in launch.json.

EDIT - Maybe I can add the directory as an environment variable in the launch.json
EDIT2 - If I add an absolute path to the rust target bin dir, it will be specific to my machine and not suitable for source control. So I do need to find a robust solution.

[bjorn3]

I believe you can use ${workspaceRoot} to reference the workspace directory. Maybe ${home} is also a thing for your user directory?

[alexmadeathing]

Good suggestion. ${home} is not valid (at least on Windows) but you can straight up reference environment variables using the windows syntax.

So I have been able to get it to work by adding the following to my launch.json:

"environment": [
    {"name":"PATH", "value":"%USERPROFILE%/.rustup/toolchains/nightly-x86_64-pc-windows-msvc/bin;${workspaceFolder}/target/debug/deps;%PATH%"}
],

I wonder if we can also get hold of the rust toolchain target as a variable...

EDIT - Included ;${workspaceFolder}/target/debug/deps in addition to the toolchain dir

[alexmadeathing]

This still doesn't feel right.

[afonsolage]

This doesn't seems like a Bevy bug, this is a problem to how VSCode Debug extensions load dynamic libs.

If you disable bevy/dynamic, it will work fine.

Any rust app that needs dynamic linking, which isn't on the SO path, will fail on this issue.

[alexmadeathing]

@afonsolage Yeah, I agree. Ok I am happy to close this issue to keep the Bevy tracker clean. I'll take it up with vscode-cpptools next.

[rzhb]

Good suggestion. ${home} is not valid (at least on Windows) but you can straight up reference environment variables using the windows syntax.

So I have been able to get it to work by adding the following to my launch.json:

"environment": [
    {"name":"PATH", "value":"%USERPROFILE%/.rustup/toolchains/nightly-x86_64-pc-windows-msvc/bin;${workspaceFolder}/target/debug/deps;%PATH%"}
],

I wonder if we can also get hold of the rust toolchain target as a variable...

EDIT - Included ;${workspaceFolder}/target/debug/deps in addition to the toolchain dir

If anyone else using CodeLLDB, the environment syntax is a little different, something like this

{
    "configurations": [
        {
            "type": "lldb",
            "env": {
                "PATH": "${env:RUSTUP_HOME}/toolchains/nightly-x86_64-pc-windows-msvc/bin;${workspaceFolder}/target/debug/deps;${env:PATH}",
            }
        }
    ]
}

[dubajj]

coming at you from 2023 where this is still an issue and the only documentation is a single comment on a bug!

I think we could add this to the Bevy book Setup page or perhaps https://bevyengine.org/learn/book/troubleshooting/

Good suggestion. ${home} is not valid (at least on Windows) but you can straight up reference environment variables using the windows syntax.

So I have been able to get it to work by adding the following to my launch.json:

"environment": [
    {"name":"PATH", "value":"%USERPROFILE%/.rustup/toolchains/nightly-x86_64-pc-windows-msvc/bin;${workspaceFolder}/target/debug/deps;%PATH%"}
],

I wonder if we can also get hold of the rust toolchain target as a variable...

EDIT - Included ;${workspaceFolder}/target/debug/deps in addition to the toolchain dir

[Atlinx]

If you're using Windows with stable rust, don't forget to change nightly-x86_64-pc-windows-msvc to stable-x86_64-pc-windows-msvc.

Here's what I ended up adding to my launch.json

"environment": [
  {
    "name": "PATH",
    "value": "%USERPROFILE%/.rustup/toolchains/stable-x86_64-pc-windows-msvc/bin;${workspaceFolder}/target/debug/deps;%PATH%"
  }
]

[alexmadeathing]

It may have been a mistake to close this, since I closed it, forgot it existed, and never followed up with vscode-cpptools. I agree we should add a work around to the troubleshooting section. I'm happy to take that on.

[alexmadeathing]

I've added a PR to the troubleshooting section of the Bevy website. In the meantime, I'm reopening this issue. Not because it's an issue with Bevy, but because I don't know exactly which extension is at fault right now.

Any ideas folks?

[mnemotic]

I'm having this same issue with RustRover. Not sure how to solve it at the moment.

[bjorn3]

You need to take the output of rustc --print target-libdir and the path to the dep dir inside the release or debug subdirectory of target and put it in the LD_LIBRARY_PATH (unix), DYLD_LIBRARY_PATH (macOS) or PATH (Windows) env var separated by ; on Windows or : on other systems when running the executable. This is necessary for the dynamic linker for find the necessary dynamic libraries.

[LouChiSoft]

I would also like to add that I have ran into the same issues using RustRover on Windows, and I have spoken to someone who has had the same behaviour using CLion and the Rust extension