-2

Background

I am modifying the source code of vim and I need to use a debugger.

Problem

Since vim is a terminal program, it takes over the terminal when it starts. So as soon as I start inside gdb, I'm just inside vim and I can't use gdb commands. When I quit vim, then I can get back to gdb but, well... then the target program ends so I can't debug it.

If I enter gdb, set breakpoints, then run vim and interact with it, my breakpoints don't actually break.

What I Tried

  1. Make sure vim is built with debug symbols (make CMAKE_BUILD_TYPE=Debug)
  2. Try with normal cgdb (VIMRUNTIME=runtime cgdb --args ./build/bin/nvim my-file)
  3. Try attaching to the process separately (sudo cgdb -p 62556)
  4. Try with some flags (VIMRUNTIME=runtime gdb ./build/bin/nvim -q --tui)

Question

How can I run gdb (or cgdb) in such a way where I can interact with gdb and also interact with the terminal program that I am debugging?

Improve this question
12
  • 3
    What was the problem when you tried attaching? And why do you use sudo? Commented Jul 15 at 17:09
  • @ssbssa When I attach without sudo, it says "Could not attach process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user." When I attach with sudo, it just doesn't do the breakpoints. For instance, I used break do_search and then c in gdb, then went to the vim process and did a search. gdb did not break at all, even though I can confirm that the do_search function is running based on some other behavior that executed properly in vim. Commented Jul 15 at 18:02
  • Did gdb say that it successfully created a breakpoint? Commented Jul 15 at 18:10
  • @ssbssa Yes. i b shows it with an address and shows an Enb value of y, which I assume means that it's enabled. Commented Jul 15 at 18:12
  • 1
    It sounds like the problem with your attach is that you are attaching to the wrong process. If you use ps or some such you should be able to identify the two vim processes, then you can attach to the correct one. You could even use add-inferior within GDB to create two inferiors, and attach to both vim processes -- breakpoints apply to all inferiors, so whichever process hits a function the breakpoint will trigger. Commented Jul 15 at 21:31

2 Answers 2

Reset to default
0

How can I run gdb (or cgdb) in such a way where I can interact with gdb and also interact with the terminal program that I am debugging?

The "standard" (and really the only) way to do that is to use two terminals: run the terminal program in one terminal and attach GDB running in another terminal.

If you need to debug the terminal program during its startup, you can use this technique.

Update:

That's what I was doing at first ... it doesn't work.

It does work, but you are likely attaching the wrong process.

Here are the steps I took:

git clone https://github.com/neovim/neovim.git
cd neovim
make CMAKE_BUILD_TYPE=Debug
VIMRUNTIME=runtime ./build/bin/nvim my-file

In ps aux, I see:

user 5756  0.0  0.0  11880  8448 pts/0    S+   08:12   0:00 ./build/bin/nvim
user 5757  0.0  0.0  15144 13056 ?        Ss   08:12   0:00 ./build/bin/nvim --embed

I can attach GDB to either nvim process, and they are doing different things.

Without knowing which of the two you attached to, and where you set your breakpoints, it's impossible to help you figure out what "didn't work".

P.S. Using sudo gdb -p ... is generally a bad idea. It is likely that your system is using YAMA, which you can disable.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

That's what I was doing at first with sudo cgdb -p 62556. I would open nvim in one tmux pane, then ps to find the pid, then cgdb in another pane. However, it doesn't work. The breakpoints don't actually break. It's because nvim launches 2 processes and I attach to the wrong one. But I don't know how to attach to the right one.
I often use ps axuf which will (I believe) list all processes. You should then be able to find the two nvim processes and attach to the right one.
> However, it doesn't work. It does work -- you must be attaching the wrong process.
I'm interested in learning how to attach the debugger to the right process. That's the whole point of the question. Until I can do that correctly, it's not working.
You have two questions: 1. How to debug terminal-using programs (which I answered) and 2. Why doesn't this work for neovim (which you didn't provide sufficient details to answer). For (2) you need to show where you are setting a breakpoint, what ps aux shows, which process you attach to, etc.
ps aux brilliant, this is the key.
-1

General Answer

The approach with cgdb -p <pid> was close, and the right idea. However, some programs (and Neovim in particular) will spawn an additional process. Sometimes that is the process to which you have to connect in order for breakpoints to work.

To properly view the list of processes, use ps aux. In this case, it shows one process for nvim and a separate process for nvim --embed. In order to debug the process, I had to connect to the --embed one.

Situation-specific Details

Neovim provides some details about how to debug the program. This is also a viable method in this case, though not generically applicable.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.