[DAP+Python] Enable debugging with Python in Helix

[nicholasjng]

I'm opening this discussion to summarize the current state of Helix debugging with Python.

What is the situation?

Using Helix's DAP implementation to debug Python scripts with a DAP client (most notably debugpy) does not quite work. But it's getting there! At HEAD, I can set breakpoints, launch templates, and inspect variables, say on this example file:

# test.py

def main():
    a = 1
    b = 2
    sum = a + b
    return sum

if __name__ == "__main__":
    main()

using the following configuration:

[[language]]
name = "python"

[language.debugger]
name = "debugpy"
transport = "stdio"
command = "python3"
args = ["-m",  "debugpy.adapter"]

[[language.debugger.templates]]
name = "source"
request = "launch"
completion = [ { name = "entrypoint", completion = "filename", default = "." } ]
args = { mode = "debug", program = "{0}"}

That results in a view such as the following:

Nice!

What are the issues?

Although there were other threads opened previously, my first issue thread (#11777) contains a crash story coming from a nonstandard event ("debugpySockets") emitted by sufficiently new versions of debugpy, that caused the Helix DAP transport to crash. This has been fixed in fec5101, and currently, we can hit breakpoints and list variables as shown above.

The remaining issues are
(1) Helix is backgrounded (backgrounding itself?) on the encounter of a breakpoint - this can be fixed with fg in zsh, and
(2) After re-foregrounding, keyboard inputs are written into the terminal window, which causes loss of control over the window, and the window filling up with the escaped contents of the user's inputs. Helix then has to be killed, to avoid writing the garbage-filled buffer to the opened file.

What is the solution?

I'm not well versed in Helix internals, and unsure what the reasons could be for the backgrounding and the buffer weirdness, but I'd like to offer my help to improve the current state. Thanks!

[nicholasjng]

Another observation: Failures in debug adapter start (e.g. because the currently available Python does not have debugpy installed) also put Helix in a weird state, albeit not completely unrecoverable (I can still issue commands like :q, :w):

Image 1: Import errors when not having the correct virtual environment activated (the part containing the output is styled in my terminal's background color) Image 2: Partial window recovery, with some misrenders visible.

Seems like the response handling from the debug adapter subprocess is not working as expected?

[pieterdd]

I attached rust-gdb to the Helix process and was able to unearth some more specific error output:

Thread 14 "hx" received signal SIGTTIN, Stopped (tty input).
main() [Switching to Thread Ox7ffffé5f46c8 (LWP 151074)]
0x000055555898dfee in rustix::backend::arch::asm::syscall3 (nr= ., al=..., a2=...) at /home/pieter/.cargo/registry/src/index.crates.i0-6f17d22bbal5601f/rustix-0.38.44/src/backend/linux_raw/arch/x86_64.rs:111

Normally I'd be able to drill down the stack trace to see exactly how we got onto this line, but Helix's GUI seems to be interfering with that. If anyone knows how to get rust-gdb to reveal this information - by writing the stack trace to a file instead of stdout for example - we might be able to diagnose the cause of the crash.

[pieterdd]

I got the stack trace. I'm not sure it brings us closer to a diagnosis though, as I don't see Helix code being referenced anywhere. Hopefully someone can decipher it.

The trace

Thread 2 "hx" received signal SIGTTIN, Stopped (tty input).
[Switching to Thread 0x7f6fa2ff76c0 (LWP 70400)]
0x0000563c31a37fee in rustix::backend::arch::asm::syscall3 (nr=...,
    a0=..., a1=..., a2=...)
    at /home/pieter/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.44/src/backend/linux_raw/arch/x86_64.rs:111
111         asm!(
(gdb) up
#1  0x0000563c31a32495 in rustix::backend::io::syscalls::read (fd=...,
    buf=0x563c4af4c888, len=1024)
    at /home/pieter/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.44/src/backend/linux_raw/arch/mod.rs:96
96              $crate::backend::arch::choose::syscall3(
(gdb) up
#2  0x0000563c31a0fe29 in rustix::io::read_write::read (fd=..., buf=&mut [u8](size=1024) = {...})
    at /home/pieter/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.44/src/io/read_write.rs:44
44          unsafe { backend::io::syscalls::read(fd.as_fd(), buf.as_mut_ptr(), buf.len()) }
(gdb) up
#3  0x0000563c31a120d3 in crossterm::terminal::sys::file_descriptor::FileDesc::read (self=0x563c4af4c820, buffer=&mut [u8](size=1024) = {...})
    at src/terminal/sys/file_descriptor.rs:80
80              let result = rustix::io::read(fd, buffer)?;
(gdb) up
#4  0x0000563c31a2c2a7 in crossterm::event::source::unix::mio::{impl#1}::try_read (self=0x563c4af4c7d0, timeout=...) at src/event/source/unix/mio.rs:96
96                                  match self.tty_fd.read(&mut self.tty_buffer) {
(gdb) up
#5  0x0000563c31a11249 in crossterm::event::read::InternalEventReader::poll (
    self=0x563c31d685c0 ,
    timeout=..., filter=0x1) at src/event/read.rs:65
65                  let maybe_event = match event_source.try_read(poll_timeout.leftover()) {
(gdb) up
#6  0x0000563c31a234a6 in crossterm::event::poll_internal (timeout=..., filter=0x1) at src/event.rs:270
270         reader.poll(timeout, filter)
(gdb) up
#7  0x0000563c31a331df in crossterm::event::stream::{impl#0}::default::{closure#0} () at src/event/stream.rs:47
47                          if let Ok(true) = poll_internal(None, &EventFilter) {
(gdb) up
#8  0x0000563c31a202b3 in std::sys::backtrace::__rust_begin_short_backtrace (f=...)
    at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/sys/backtrace.rs:154
154         let result = f();
(gdb) up
#9  0x0000563c31a066b4 in std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure#0} ()
    at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/thread/mod.rs:522
522                     crate::sys::backtrace::__rust_begin_short_backtrace(f)
(gdb) up
#10 0x0000563c31a27e64 in core::panic::unwind_safe::{impl#23}::call_once<(), std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}> (self=...)
    at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/panic/unwind_safe.rs:272
272             (self.0)()
(gdb) up
#11 0x0000563c31a18761 in std::panicking::try::do_call>, ()> (data=0x7f6fa2ff6a90)
    at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:554
554                 data.r = ManuallyDrop::new(f());
(gdb) up
#12 0x0000563c31a0885b in __rust_try ()
(gdb) up
#13 0x0000563c31a06339 in std::panicking::try<(), core::panic::unwind_safe::AssertUnwindSafe>> (f=...)
    at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:518
518             return if intrinsics::catch_unwind(do_call::, data_ptr, do_catch::) == 0 {
(gdb) up
#14 std::panic::catch_unwind>, ()> (f=...)
    at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panic.rs:345
345         unsafe { panicking::r#try(f) }
(gdb) up
#15 std::thread::{impl#0}::spawn_unchecked_::{closure#1} ()
    at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/thread/mod.rs:521
521                 let try_result = panic::catch_unwind(panic::AssertUnwindSafe(|| {
(gdb) up
#16 0x0000563c31a0d02f in core::ops::function::FnOnce::call_once, ()> ()
    at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/ops/function.rs:250
250         extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
(gdb) up
#17 0x0000563c31ad5b3b in alloc::boxed::{impl#48}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> ()
    at alloc/src/boxed.rs:2231
2231            >::call_once(*self, args)
(gdb) up
#18 alloc::boxed::{impl#48}::call_once<(), alloc::boxed::Box, alloc::alloc::Global>, alloc::alloc::Global> () at alloc/src/boxed.rs:2231
2231            >::call_once(*self, args)
(gdb) up
#19 std::sys::pal::unix::thread::{impl#2}::new::thread_start ()
    at std/src/sys/pal/unix/thread.rs:105
105                     Box::from_raw(main as *mut Box)();
(gdb) up
Downloading 34.84 K source file /usr/src/debug/glibc-2.41/nptl/pthread_create.c
#20 0x00007f6fb0a9a7be in start_thread (arg=)
    at pthread_create.c:448
448             ret = pd->start_routine (pd->arg);
(gdb) up
Downloading 2.48 K source file /usr/src/debug/glibc-2.41/misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S
#21 0x00007f6fb0b1edcc in __GI___clone3 ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
78              call    *%rdx           /* Call function.  */
(gdb) up
Initial frame selected; you cannot go up.

[pieterdd]

The most interesting piece of information perhaps is that the thread received a SIGTTIN. This is described as:

A process cannot read from the user’s terminal while it is running as a background job. When any process in a background job tries to read from the terminal, all of the processes in the job are sent a SIGTTIN signal. The default action for this signal is to stop the process. For more information about how this interacts with the terminal driver, see Access to the Controlling Terminal.

Any chance debugpy is trying to read stdin while running as a background process?

[maxtheman]

@pieterdd can you provide reproduction instructions for how you retrieved that stack trace? I'd like to take a swing at it, and your direction seems promising.

[pieterdd]

I set up two separate terminals so the output would not intermingle. Since you normally can't debug arbitrary processes for security reasons, you need to whitelist Helix.

1. Check out the Helix codebase
2. Add the libc dependency
3. To the top of the main function (somewhere in helix-term), add unsafe { prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY) };
4. Run cargo build
5. Run target/debug/hx in the first terminal
6. Get the PID of the running progress
7. In the second terminal, run rust-gdb
8. At the gdb prompt, enter attach [ID of the process]

You should now be in a debugging session. When you replicate the crash scenario you should get the stack trace.

[nicholasjng]

Reproduction steps with the above script Python script as test.py:

Either with python3 itself or uv (which I use for simplicity):

1. python3 -m venv .venv / uv venv --seed -p 3.X (X being your minor Python version of choice)
2. source .venv/bin/activate
3. pip install --upgrade debugpy
4. hx test.py

The key sequence:

1. jjjjj <space>-G-b-l (go down to L6, i.e. the return sum statement, set breakpoint, go into launch target menu)
2. Enter+t+<tab>+Enter (should select test.py from the file completion menu)
3. Debugging starts, L6 gets highlighted due to breakpoint activation
4. Press any key, now Helix is backgrounded. You end up in a shell prompt, invoke fg to foreground Helix again.
5. Type :v (colon in front is important) to list variables. This should launch an overlay containing the values as seen in the screenshot.
6. After this, it seems the editor is screwed up, and exiting via :q! is no longer possible.

[GlennWSo]

In the current (master) Is it possible to setup some log so that one can see the output of print("something")