Want to hear a feedback on debugging support

Community
1

Hello, Ladies and Gentlemen,

I am back in the game and want to ask some questions regarding debugging support:

What are your current pain points with debugging support?

Is anyone using VS Code with CodeLLDB for debugging, or do you prefer some other IDEs for Crystal?

I am trying to plan my time and help solve the most painful debugging issues before I retool myself for other parts of the project (it could be interpreter or IDE tooling for Crystal or native support for Crystal in LLDB).

Based on what I hear from conducting user interviews, the biggest issue is DX (developer experience), and debugging support, as well as Crystal plugins for popular IDEs, is one of them that may stall the adoption of Crystal by the wider community.

So I would gladly accept any suggestions.

7 Likes
2

I pretty much use Emacs exclusively for an IDE, and would prefer to use GDB from the command line for a debugger instead of LLDB. But tbh, 95% of the time I just use puts and pp. The biggest issue I run into while debugging is build times vs a binary that’s actually performant enough to use.

3

Debug: I debug in GDB directly (Linux). I also tried WinDBG on Windows to debug a segfault, and it just worked. I heard that the integration with the vscode debugger doesn’t work (but maybe you need a plugin).

That being said the GDB command line is very powerful but the DX ain’t intuitive (must learn all those commands); the SeerGDB GUI is nice but not as powerful as the CLI (of course).

Related: the addition of tracing is helping me a lot. I’m wondering about adding an app section for anyone to add custom tracing (interleaved with gc, sched, evloop, …).

Tooling: there are good things already, but I heard that Crystal tooling, such as LSP, is ages away from Rust tooling for example.

1 Like
4

I used to use vi on the remote shells, but for the last twenty years, I have rarely used it. I use Midnight Commander most of the time, and mcedit is my main editor.

When I started working on Crystal debugging support, I used a lot of logging.
It generated nearly a gigabyte of logs and was nearly impossible to analyze.

When I finally got some working code, I started debugging the debugging support, which greatly sped development up. So, I have been programming for the last 41 years (since I was ten years old).

Debuggers are an important part of my life, so in 2019, I decided to spend the time and implement it to help myself use the Crystal at its full potential.

Usually, compile times are quite fast when compiling with debugging support, as it disables most optimizations.

4 Likes
5

I use macOS, so gdb does not work there (it hangs OS badly, so you will have to reboot :frowning: ), so lldb works like a charm.

lldb supplied with macOS does not have Python scripting enabled by default, so you must build your version with enabled Python support.
After that, my scripts started showing Crystal strings and arrays quite properly.

As for tooling, I was planning to spend some time on debugging support improvement and then spend some time on LSP and IDE plugins around it.

1 Like
6

Is there a tutorial somewhere about setting up lldb with those scripts?

I have been somewhat frustrated by the debugging experience (as in: I can’t debug much)

2 Likes
8

https://dev.to/bcardiff/debug-crystal-in-vscode-via-codelldb-3lf

2 Likes
9

Ok, I debug with pp, but if normal debugging would be possible it would be great. I tried to use CodeLLDB on Windows:

thread ‘main’ panicked at ‘called Result::unwrap() on an Err value: “Could not load "c:\\Users\\\username\\.vscode\\extensions\\vadimcn.vscode-lldb-1.10.0\\lldb\\bin\\liblldb.dll" (err=0x0000007E)”’

dll is present on this path and dependencies looks ok (lldb.exe in the same folder runs without error), but i guess something is wrong.

10

BTW, i followed this post, and tested on a lucky project recently. it works on my arch linux with lldb/llvm 18.1.18, crystal 1.13.2, codelldb plugin version 1.10.0 on code 1.93.1

Following is screenshot.

image
image3150×1839 460 KB

.vscode/launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "crystal: debug current file",
            "preLaunchTask": "crystal: build current file (debug)",
            "program": "${workspaceFolder}/bin/website",
            "args": [],
            "cwd": "${workspaceFolder}",
            "initCommands": [
                "command script import /home/zw963/Crystal/crystal-lang/crystal/etc/lldb/crystal_formatters.py"
            ]
        }
    ]
}

.vscode/tasks.json

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "crystal: build current file (debug)",
      "type": "shell",
      "command": "crystal build --debug src/website.cr -o bin/website"
    }
  ]
}
12

I will try to find some time to play with Crystal::Tracing, so it can be quite interesting.

13

I didn’t have a chance to check it on Windows as I stopped using it about ten years ago, so I am mostly a Mac guy these days.

I hope that someone was able to reproduce it. If not, then I will try то find my old license with Windows 11 and install it on VM.

14

I had some success and problems on windows -

15

@ComputerMage something I struggle with debug info is how to access globals, be they constants or class variables. There are no issues with local vars and args, but I’m at a complete loss with inspecting globals…

16

Hey Julien,

Great to hear from you!
I did a brief investigation, and I can see that you can see some of the class/static variables, but not in the way you expect.
LLDB does not know how to parse Crystal syntax for the class:

(lldb) p String::CHAR_TO_DIGIT62:const_init
error: <user expression 105>:1:9: no member named 'CHAR_TO_DIGIT62' in 'String'
    1 | String::CHAR_TO_DIGIT62:const_init
      | ~~~~~~~~^

so I will investigate further if I can access it via python API.

1 Like