Bug: The debug adapter has terminated abnormally.

[nurmohammed840]

Trying to debug some async rust code.

#[tokio::test]
async fn test_async_binary_semaphone() {
    let s = tokio::sync::Semaphore::new(1);   // add a breakpoint, at this line
    println!("{:?}", s.available_permits());
    let sp = s.acquire().await.unwrap();
    println!("{:?}", s.available_permits());
    drop(sp); // release the permit
}

Cargo.toml file:

[dependencies]
tokio = { version = "1", features = ["full"] }

This would create this error:

configuration: {
  type: 'lldb',
  request: 'launch',
  name: 'test test_async_binary_semaphone',
  program: '${workspaceFolder}\\target\\debug\\deps\\page_lock-fb9ac44b70f6a5b8.exe',
  args: [ 'test_async_binary_semaphone', '--exact', '--nocapture' ],
  cwd: '${workspaceFolder}',
  sourceLanguages: [ 'rust' ],
  ...
}
Listening on port 14341
error: page_lock-fb9ac44b70f6a5b8.exe :: Class 'core::future::from_generator::GenFuture<tokio::net::windows::named_pipe::impl$4::ready::generator$0>' has a member '__0' of type 'generator$0' which does not have a complete definition.
[adapter\src\terminal.rs:104] FreeConsole() = 1
[adapter\src\terminal.rs:105] AttachConsole(pid) = 1
[adapter\src\terminal.rs:109] FreeConsole() = 1
error: page_lock-fb9ac44b70f6a5b8.exe :: Class 'enum$<core::option::Option<core::ptr::non_null::NonNull<tokio::runtime::task::core::Header> >, 1, 18446744073709551615, Some>::Some' has a member '__0' of type 'core::ptr::non_null::NonNull<tokio::runtime::task::core::Header>' which does not have a complete definition.
error: page_lock-fb9ac44b70f6a5b8.exe :: Class 'tokio::util::linked_list::PointersInner<tokio::io::driver::scheduled_io::Waiter>' has a member 'prev' of type 'enum$<core::option::Option<core::ptr::non_null::NonNull<tokio::io::driver::scheduled_io::Waiter> >, 1, 18446744073709551615, Some>' which does not have a complete definition.
error: page_lock-fb9ac44b70f6a5b8.exe :: Class 'tokio::util::linked_list::PointersInner<tokio::time::driver::entry::TimerShared>' has a member 'prev' of type 'enum$<core::option::Option<core::ptr::non_null::NonNull<tokio::time::driver::entry::TimerShared> >, 1, 18446744073709551615, Some>' which does not have a complete definition.
error: page_lock-fb9ac44b70f6a5b8.exe :: Class 'tokio::util::linked_list::PointersInner<tokio::sync::notify::Waiter>' has a member 'prev' of type 'enum$<core::option::Option<core::ptr::non_null::NonNull<tokio::sync::notify::Waiter> >, 1, 18446744073709551615, Some>' which does not have a complete definition.
error: page_lock-fb9ac44b70f6a5b8.exe :: Class 'tokio::util::linked_list::PointersInner<tokio::sync::batch_semaphore::Waiter>' has a member 'prev' of type 'enum$<core::option::Option<core::ptr::non_null::NonNull<tokio::sync::batch_semaphore::Waiter> >, 1, 18446744073709551615, Some>' which does not have a complete definition.

thread 'main' has overflowed its stack
Debug adapter exit code=3221225725, signal=null.

[chamons]

I can independently reproduce this on my own tokio project as well.

The only work around I can find is to keep the variables window minimized and use only the watch window.

[vadimcn]

3221225725 = 0xc00000fd aka "stack overflow"

[eternal-devs-yk]

@chamons thank you. same here.

[eternal-devs-yk]

@vadimcn the same my project does not reproduce the issue when I build on: Default host: x86_64-unknown-linux-gnu stable-x86_64-unknown-linux-gnu (default) rustc 1.60.0 (7737e0b5c 2022-04-04)

It happens on Windows.

[mad-rain]

Hi!

The issues doesn't reproduce on macOS for me, but it does on Windows.

[Trenrod]

Same here but as a workaround I`m using

"type": "cppvsdbg", instead of "type": "lldb".

https://github.com/vadimcn/vscode-lldb/issues/635#issuecomment-1047011456 does not worked for me.

[mankinskin]

"type": "cppvsdbg", instead of "type": "lldb".

Does not work for me, I get: "Error processing launch options at field: program"

[Peter-J-Jansen]

I get the very same error:

thread 'main' has overflowed its stack
Debug adapter exit code=3221225725 (0xc00000fd), signal=null.

Is this problem still being worked on, or should we just forget CodeLLDB on VScode under Windows, like delete that product version / platform forever ?

Cheers,

Peter

[vadimcn]

Is this problem still being worked on ... ?

Not directly. I do upgrade the bundled LLDB when a new version comes out, so bugs might get fixed eventually. Currently I am preparing a release based on LLDB v16, you can try it out here.

[Peter-J-Jansen]

Thanks for the feedback.

Whilst still hopeful that this issue on Windows may get fixed one day, for now I decided to switch to Linux (Ubuntu 18.04). And there my debugging works fine; no problems encountered yet.

Cheers,

Peter

[vadimcn]

@Peter-J-Jansen Would you mind checking if you still get a stack overflow on Windows with that build?

[Peter-J-Jansen]

OK, I'll try to do that the next few days. I've already downloaded "codelldb-x86_64-windows.vsix" (about 40 MB), but how do I go about and update what I current have on vscode ? So far I've only ever installed vscode extensions by clicking on the "install" button they all have. And if this ".vsix" makes things worse, how can I back out and revert to what I have right now ?

Cheers,

Peter

[vadimcn]

I've already downloaded "codelldb-x86_64-windows.vsix" (about 40 MB), but how do I go about and update what I current have on vscode

Use "Extensions: Install from VSIX" command, pick the file you've downloaded.

And if this ".vsix" makes things worse, how can I back out and revert to what I have right now ?

Open the Extensions side panel, find CodeLLDB, click the gear button, choose "Install Another Version...".

[Peter-J-Jansen]

Thanks Vadim. The vsix install worked fine. But when trying to re-test the stack overflow, I now don't seem to be able to get even that far. The debug start (SDL-hyperion) uses an "attach", and that appears to work, except that then my breakpoints, marked by red dots, all disappear; they are replaced by white circles. If I hover over them, a message saying "Resolved locations : 0" appears. The breakpoints do not work however, they don't get triggered.

I've left this pre-release CoreLDDB in place, perhaps you have suggestions. In the mean time I keep on using the regular CoreLLDB on Lubuntu 20.04, which seems to work fine.

Cheers,

Peter

[johanhelsing]

Minimal test case. cargo new --lib borked_test and paste the following in lib.rs:

#[cfg(test)]
mod test {
    fn get_foo_fn() -> impl Fn() -> () {
        let foo = 0;
        move || {
            // put a breakpoint here to trigger a stack overflow when starting debugging
            let _a = foo;
        }
    }

    #[test]
    // as long as I'm present, I will bork debugging
    fn bork_debugging() {
        let _ = get_foo_fn();
    }

    #[test]
    fn empty_test() {
        // trying to debug me will trigger a stack overflow
    }
}

CodeLLDB: 1.9.0

TL;DR: Workaround is to not put breakpoints in capturing lambdas returned by functions. Or I guess just try to disable all your breakpoints and see if that helps.

[vadimcn]

@johanhelsing -msvc target? Yeah, that's known to happen...

[Barafu]

If I use "launch" rerquest in launch.json instead of "cargo", the debugger always crashes like that? not sometimes.

{
        "type": "lldb",
        "name": "Tauri Development Debug",
        "request": "launch",
        "program": "${workspaceFolder}/src-tauri/target/debug/dream_spinner.exe",        
        "preLaunchTask": "rust: cargo build devel",        
      },