Most people are probably familiar with gdb, and Ribamar pointed out to me there is also a ncurses frontend inside gdb.
But in case anyone is interested I learned that NetBeans also supports remote debugging. Even though it's not the most modern IDE in the world, and it's vi emulation is cumbersome , it seems to have pretty good support for remote-debugging.
It will just login to some machine via ssh (i.e., dev11 or a real cluster), and issue gdb <something> and wrap around it. If you make sure it knows where the sources files are on your development machine, you can use all the step-debugging features.

The only downside is that loading up cmd in gdb takes a while probably ~ 30 seconds. Still it's a lot faster than debugging with print-statements and recompiling.
For cmsh it's already a lot faster and on top of that you can issue a command multiple times via the REPL, so you can step debug it multiple times within the same gdb session.
(Beware though that you probably need to connect again as your connection may be lost)

Example workflow

To show off how it works first with CMDaemon. My workflow is to create a unit-test that fails, set a breakpoint in the unit-test and start the debug.

→ break point set followed by the debugger stopping execution at that point.

→ step-into example, select the function to step into ➀ and click the button highlighted with ➁.

There is also the F7 key to "step into", but be prepared to step into assembly a lot of times (use CTRL+F7 to step out, and try again).
You will jump into the -> operator, shared pointer dereferences, std::string constructors, before getting into the function you want.
(Also note that the first time you step into assembly it will be very slow, but it will get faster the next few times).

Wizard example to debug cmd unit test

Note that you want to set some bogus command like whoami.
Netbeans will try to be smart and clean your project directory for you
(and rebuild without using multiple cores, ..)

Note the working directory should be including src.
This is to help gdb later with finding source code.

There is one fix needed that the Wizard didn't set properly for us.
Go to project properties, Build / Make, and set Build Result to the executable.
The remote debugger will use this value for issuing with gdb, and it's somehow empty by default.

Use ALT+SHIFT+o to Jump to the file containing the test.
Set a breakpoint there using CTRL+F8

The final thing we want to pass to gdb is the parameters for running our specific unittest.
In my example "${OUTPUT_PATH}" --unittests --gtest_filter=LineParserTest.empty.

You can use these settings to double check if everything is correct

Thanks for the tutorial. I was trying to follow your tutorial and stumbled upon this error as described in this stackoverflow page. It still remains unanswered, do you have any suggestion? It gets stuck if you need to debug the remote program with sudo permissions.

Thanks,
Arvind

Arvind

2018-08-14 18:53:42

Hi,

Thanks for the tutorial. I was trying to follow your tutorial and stumbled upon this error as described in this stackoverflow page. It still remains unanswered, do you have any suggestion? It gets stuck if you need to debug the remote program with sudo permissions.

Thanks,
Arvind

Leave a Reply

Name (required)

Mail (optional, NEVER displayed!)

Website (optional)

Comment may not be visible immediately, because I process everything manually.**