nushell: Launching in the VS Code LLDB debugger causes a panic

Describe the bug

Problem arises from a change in #6584:

Trying to launch interactive nushell via the CodeLLDB VS Code extension causes a panic on this line.

grafik

It appears that fd 0 is a valid tty and the atty crate is reporting the same thing. I don’t fully grasp how we can deal with the other error cases vaguely described in https://man7.org/linux/man-pages/man3/tcgetpgrp.3.html

How to reproduce

Install VS code and the CodeLLDB VS Code extension Setup the launch.json automatically based on the cargo workspace. Launch the nu executable via the Debugger (F5).

Reproducibility notes: both on Ubuntu standalone and with WSL2 I was able to cause this crash (for the external and internal terminal option in the launch.json config).

Expected behavior

Any failure to get those process groups should not kill the application. Having the option to debug nushell interactively that way is valuable (even if we might deviate from some regular behavior in a documented way to achieve that).

Screenshots

No response

Configuration

key	value
version	0.69.2
branch	alias_fix
commit_hash	f0584601a2c6ec6f2bdf65ae1cc41903d779aee3
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.63.0 (4b91a6ea7 2022-08-08)
rust_channel	1.63.0-x86_64-unknown-linux-gnu
cargo_version	cargo 1.63.0 (fd9c4297c 2022-07-01)
pkg_version	0.69.2
build_time	2022-10-14 21:46:53 +02:00
build_rust_channel	debug
features	default, trash, which, zip
installed_plugins

Additional context

Launching gdb target/debug/nu was not picking up this panic if I get this correctly (but my gdb foo is not strong enough to properly launch nu in a separate terminal while being attached from the start.) Regular late attaching with gdb -p <nu pid> was not causing unexpected problems.

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 1
Comments: 19 (17 by maintainers)

Most upvoted comments

I’m also having issues using lldb and TTY. But it works well if I use lldb attach when I start the debug version of the built binary.

{
    "type": "lldb",
    "request": "attach",
    "name": "Attach",
    "pid": "${command:pickMyProcess}" // use ${command:pickProcess} to pick other users' processes
}

alesito85 on Feb 9, 2023

I am getting the same panic/message on linux when running nu through my window manager (sway). (E.g., using a key binding to run a nu script.) By launching nu this way, I assume there is no ‘controlling terminal’ which is why ENOTTY is encountered. Correct me if I’m wrong, but I believe that encountering ENOTTY should not mean an immediate panic. There is even a check for this, but it is never reached due to the panic. Also, this is with nu version 0.70.0 (the latest package release for arch).

IanManske on Oct 19, 2022

Thanks for you guys sharing, I’d figured it out but forgot to leave some step-by-step instruction in case someone like me having the same issue

I am taking my Linux devbox as example:

Install GDB sudo apt intstall gdb, you could change the command if you are on different distro
You need a compiled dev bin which is in nushell/target/dev folder
Run your local nu bin ./nu, you also want to find the running PID by ps | where name =~ 'nu' | where status == 'Running'
run gdb
Attach nu PID by attach <PID>
Set breakpoint by break <file>:<line>

Kangaxx-0 on Dec 25, 2022

VSCode + LLDB is the only way I debug Rust code, if you guys has another way to debug day to day, I’d like to learn from you 😃

Kangaxx-0 on Nov 23, 2022