Workaround Linux: No Call Stack on first breakpoint

[tigerbeard]

There is a debug issue with CodeBlocks for some time (at least 3 years) that I found a bit annoying. I am posting this because I did not see the (obvious) workaround until recently and in case I am not the oly one  .

The issue is that the call stack it not filled at the first stop after a start in Debug mode.
It works fine after the first manual debug step. Its easy to workaround by just setting the breakpoints one step ahead of the actual target except when trying the debug a crash. Then I needed an otherwise unneeded breakpoint at the very start of the program so it would have a safe stop before the crash.

What I missed is that the call stack is actually there, it seems that the very first CallStack window update is lost for some reason. Disabling and re-enabling the CallStack window with the debug tool bar icon "debug windows" the call stack is visible directly even at the first stop.

But I also found that a CallStack Window open by default is one of the 3 things that can slow down the debugger qute a lot, at least for large projects. It got the single step time down from 10sec to 1sec with the CodeBlocks source with those settings

• CallStack window closed.
• debug option "Watch function arguments" disabled
• debug option "Watch local variables" disabled

The final must-know on Linux debuging is that breakpoints set before debugger start can not be removed during runtime except manually with GDB commands. The broken breakpoints can be seen in the breakpoint window to show the index "-1". The can be removed in the Debugger window by using the two gdb commands "info break" and "del break N" with N the breakpoint number as listed in the info command output.

happy debugging


Note: Issues seen in Ubuntu Linux 22.04 and 18.04 (trunk compiled with GTK3.0). Might be Linux only.

[ollydbg]

Thanks for the reporting.

I use C::B in every day development. I see those issues to.

The big issue could be the current way C::B communicate with GDB, it is purely command line(CLI) interface. It could be better if we use the Machine interface(MI), obf has implement some functions, but his contribution is not in the our svn trunk. I believe he has a git repo(I can't find anywhere recently), I built his MI interface plugin several years ago, and at least it worked for basic debugging.

Unluckily, obf currently is not active in our forum. 

[tigerbeard]

I use C::B in every day development. I see those issues too.

Well, at least good to know that this is not some local issue in my installation.


The really nagging thing in daily use imho is the breakpoints.
The code interface is a bit cumbersome but not too hard to understand - at least for the breakpoints. The main issue I see is that it does look at the async gdb repies but passes them on to the n-th class for processing assuming the replies are in the same number and order than the initial commands. That fails with the pre-start breakpoints as I had described in Ticket 174.

My hack I described there tried to correct the async reply order by inserting dummy steps when required. That does principally work but not in practical use where only some breakpoints are recovered. And its not a good solution anyway.
A far better way would be for initial start to save all outgoing commands in a list with the issuer (e.g. a vector of std:pairs) and offer each reply to all classes in that list for parsing. That way the interface would be robust against reordering and added or left out replies. The disadvantage that its a larger code change and would also make the breakpoint class (an other classes) parsing more involved. A change with potential to break something else by accident. I am not well enough into the code to try that.

Some years ago there was some not of a new gdb control interface that would allow direct interaction without parsing. Not sure where that went, but probably that would allow for some new freatures like function return values.

[Pecan]

For reference: Related:
Ticket #1460 and #174