User forums > Using Code::Blocks
Linux: gdb ignores removed breakpoints
AndrewCot:
I would see if you can install a later GDB as besides the break point issue there is also a memory watch that is not working as the "x/256xb 0x0" is the GDB annotations way of reading memory (GDB/MI is different), but the address is 0x0 and as such GDB complains that it "Cannot access memory at address 0x0". I have seen this when I had not coded things up correctly and was trying to watch a variable, but the variable was converted to a long and as you can appreciate it failed so the address became 0, which once I finished the changes for supporting memory read using variables it worked.
The break point number is returned by GDB when you set a break point and this is the number reported in the log. I have also seen where GDB does not re-se them.
Unfortunately the existing GDB logging is lacking info. It could be related to threading as I have not looked at multiple threading, apart from getting the threading dialog working (or what looks like working).
The following is an example of the GDB/MI logging, which has allot more usable debugging info to show you what GDB/MI plugin and GDB are doing:
--- Code: ---[debug ] <std::shared_ptr<cbBreakpoint> Debugger_GDB_MI::AddBreakpoint(L 1349)> D:\Andrew_Development\Z_Testing_Apps\Printf_I64\main.cpp:130
[debug ] < dbg_mi::GDBBreakpointAddAction::OnStart(L 122)> GDBBreakpointAddAction::m_initial_cmd = 110000000000
[cmd ] < dbg_mi::CommandExecutor::ExecuteSimple(L 77)> cmd==>110000000000-break-insert -f D:\Andrew_Development\Z_Testing_Apps\Printf_I64\main.cpp:130==<
[info ] < dbg_mi::CommandExecutor::ProcessOutput(L 93)> Receive ==>110000000000^done,bkpt={number="4",type="breakpoint",disp="keep",enabled="y",addr="0x00007ff7af9c197b",func="main()",file="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",fullname="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",line="130",thread-groups=["i1"],times="0",original-location="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp:130"}<==
{Receive } < Debugger_GDB_MI::OnGDBOutput(L 274)> Ignore =>(gdb) <=
[info ] <dbg_mi::ResultParser* dbg_mi::CommandExecutor::GetResult(L 257)> Parsing: id: 110000000000 parser ==>type: result , ClassDone , { m_value results: {bkpt={number=4,type=breakpoint,disp=keep,enabled=y,addr=0x00007ff7af9c197b,func=main(),file=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,fullname=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,line=130,thread-groups=["i1"],times=0,original-location=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp:130}} }<== for ==>^done,bkpt={number="4",type="breakpoint",disp="keep",enabled="y",addr="0x00007ff7af9c197b",func="main()",file="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",fullname="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",line="130",thread-groups=["i1"],times="0",original-location="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp:130"}<==
[debug ] <dbg_mi::GDBBreakpointAddAction::OnCommandOutput(L 54)> Currently disabled id: 110000000000 index is 4 for =>type: result , ClassDone , { m_value results: {bkpt={number=4,type=breakpoint,disp=keep,enabled=y,addr=0x00007ff7af9c197b,func=main(),file=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,fullname=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,line=130,thread-groups=["i1"],times=0,original-location=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp:130}} }<=
[debug ] <dbg_mi::GDBBreakpointAddAction::OnCommandOutput(L 92)> finishing for id: 110000000000 for =>type: result , ClassDone , { m_value results: {bkpt={number=4,type=breakpoint,disp=keep,enabled=y,addr=0x00007ff7af9c197b,func=main(),file=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,fullname=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,line=130,thread-groups=["i1"],times=0,original-location=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp:130}} }<=
[info ] <dbg_mi::GDBBreakpointAddAction::~GDBBreakpointAddAction(L 29)> GDBBreakpointAddAction::destructor
[debug ] < Debugger_GDB_MI::Continue(L 1202)> Debugger_GDB_MI::Continue
[cmd ] < Debugger_GDB_MI::CommitRunCommand(L 1142)> =>-exec-continue<=
[debug ] <dbg_mi::GDBRunAction<StopNotification>::OnStart(L 112)> GDBRunAction::OnStart -> -exec-continue
[cmd ] < dbg_mi::CommandExecutor::ExecuteSimple(L 77)> cmd==>120000000000-exec-continue==<
[info ] < dbg_mi::CommandExecutor::ProcessOutput(L 93)> Receive ==>120000000000^running<==
[info ] < dbg_mi::CommandExecutor::ProcessOutput(L 93)> Receive ==>*running,thread-id="all"<==
{Receive } < Debugger_GDB_MI::OnGDBOutput(L 274)> Ignore =>(gdb) <=
[info ] < dbg_mi::CommandExecutor::ProcessOutput(L 93)> Receive ==>=breakpoint-modified,bkpt={number="4",type="breakpoint",disp="keep",enabled="y",addr="0x00007ff7af9c197b",func="main()",file="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",fullname="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",line="130",thread-groups=["i1"],times="1",original-location="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp:130"}<==
{Receive } < Debugger_GDB_MI::OnGDBOutput(L 274)> Ignore =>~"\n"<=
{Receive } < Debugger_GDB_MI::OnGDBOutput(L 274)> Ignore =>~"Thread 1 hit Breakpoint 4, main () at D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp:130\n"<=
{Receive } < Debugger_GDB_MI::OnGDBOutput(L 274)> Ignore =>~"\032\032D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp:130:3113:beg:0x7ff7af9c197b\n"<=
[info ] < dbg_mi::CommandExecutor::ProcessOutput(L 93)> Receive ==>*stopped,reason="breakpoint-hit",disp="keep",bkptno="4",frame={addr="0x00007ff7af9c197b",func="main",args=[],file="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",fullname="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",line="130",arch="i386:x86-64"},thread-id="1",stopped-threads="all"<==
{Receive } < Debugger_GDB_MI::OnGDBOutput(L 274)> Ignore =>(gdb) <=
---------------
{Receive } <dbg_mi::ResultParser* dbg_mi::CommandExecutor::GetResult(L 265)> Parsing : id: 120000000000 parser ==>type: result , ClassRunning<== for ==>^running<==
[debug ] <dbg_mi::GDBRunAction<StopNotification>::OnCommandOutput(L 101)> GDBRunAction success, the debugger is !stopped!
[debug ] <dbg_mi::GDBRunAction<StopNotification>::OnCommandOutput(L 102)> GDBRunAction::Output - type: result , ClassRunning
[debug ] < dbg_mi::GDBExecutor::Stopped(L 325)> Executor started
---------------
{Receive } <dbg_mi::ResultParser* dbg_mi::CommandExecutor::GetResult(L 265)> Parsing : id: -1-000000001 parser ==>type: exec-async-ouput , ClassRunning , { m_value results: {thread-id=all} }<== for ==>*running,thread-id="all"<==
---------------
{Receive } < Notifications::operator()(L 479)> notification event received: ==>type: exec-async-ouput , ClassRunning , { m_value results: {thread-id=all} }<==
[info ] <dbg_mi::ResultParser* dbg_mi::CommandExecutor::GetResult(L 257)> Parsing: id: -1-000000001 parser ==>type: notify-async-ouput , class unknown , { m_value results: {bkpt={number=4,type=breakpoint,disp=keep,enabled=y,addr=0x00007ff7af9c197b,func=main(),file=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,fullname=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,line=130,thread-groups=["i1"],times=1,original-location=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp:130}} }<== for ==>=breakpoint-modified,bkpt={number="4",type="breakpoint",disp="keep",enabled="y",addr="0x00007ff7af9c197b",func="main()",file="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",fullname="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",line="130",thread-groups=["i1"],times="1",original-location="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp:130"}<==
{Receive } < Notifications::ParseNotifyAsyncOutput(L 600)> Notification for breakpoint-modified: type: notify-async-ouput , class unknown , { m_value results: {bkpt={number=4,type=breakpoint,disp=keep,enabled=y,addr=0x00007ff7af9c197b,func=main(),file=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,fullname=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,line=130,thread-groups=["i1"],times=1,original-location=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp:130}} }
[info ] <dbg_mi::ResultParser* dbg_mi::CommandExecutor::GetResult(L 257)> Parsing: id: -1-000000001 parser ==>type: exec-async-ouput , ClassStopped , { m_value results: {reason=breakpoint-hit,disp=keep,bkptno=4,frame={addr=0x00007ff7af9c197b,func=main,args=[],file=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,fullname=D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp,line=130,arch=i386:x86-64},thread-id=1,stopped-threads=all} }<== for ==>*stopped,reason="breakpoint-hit",disp="keep",bkptno="4",frame={addr="0x00007ff7af9c197b",func="main",args=[],file="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",fullname="D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp",line="130",arch="i386:x86-64"},thread-id="1",stopped-threads="all"<==
< Notifications::ParseStateInfo(L 533)> Breakpoint hit on line#: 130 in file: D:\\Andrew_Development\\Z_Testing_Apps\\Printf_I64\\main.cpp
[debug ] < dbg_mi::GDBExecutor::Stopped(L 321)> Executor stopped
[debug ] <dbg_mi::GDBRunAction<StopNotification>::~GDBRunAction(L 94)> GDBRunAction::destructor
[debug ] < dbg_mi::GDBWatchesUpdateAction::OnStart(L 1660)> -var-update 1 *
[cmd ] < dbg_mi::CommandExecutor::ExecuteSimple(L 77)> cmd==>130000000000-var-update 1 *==<
[info ] < dbg_mi::CommandExecutor::ProcessOutput(L 93)> Receive ==>130000000000^done,changelist=[{name="var1",value="7",in_scope="true",type_changed="false",has_more="0"}]<==
{Receive } < Debugger_GDB_MI::OnGDBOutput(L 274)> Ignore =>(gdb) <=
[info ] <dbg_mi::ResultParser* dbg_mi::CommandExecutor::GetResult(L 257)> Parsing: id: 130000000000 parser ==>type: result , ClassDone , { m_value results: {changelist=[{name=var1,value=7,in_scope=true,type_changed=false,has_more=0}]} }<== for ==>^done,changelist=[{name="var1",value="7",in_scope="true",type_changed="false",has_more="0"}]<==
[debug ] <dbg_mi::GDBWatchesUpdateAction::ParseUpdate(L 1679)> List count: 1 , result: ==>type: result , ClassDone , { m_value results: {changelist=[{name=var1,value=7,in_scope=true,type_changed=false,has_more=0}]} }<==
[debug ] <dbg_mi::GDBWatchesUpdateAction::ParseUpdate(L 1773)> Update ==>var1<<== = ==>7<<==
[debug ] <dbg_mi::GDBWatchesUpdateAction::OnCommandOutput(L 1832)> WatchUpdateAction::Output - finishing at==>130000000000<<==
[debug ] < dbg_mi::UpdateWatches(L 1125)> updating watches
--- End code ---
tigerbeard:
I new nothing about GDB/MI or the plugin, but just checked out this thread.
https://forums.codeblocks.org/index.php/topic,24694.0.html?PHPSESSID=f4cf192e67e1c69570e79e98afe402e6
The Ubuntu repository does not seem to have a special GDB/MI I only found something like a perl addon referencing it. Is the MI part of the standard gdb?
Using a better interface than CLI parsing is a great idea and hopefully makes things less complicated in the future. There are also some interesting features possible like function return values. Sound promising. And a lot happening at the moment. Thanks for your efforts!
I am aware that the log is incomplete, I thought the sections at least show there there is a BP number mixup. When I have got something more useful I will post it
Not sure if i got your point with the 0x0, though. I did have a number of invalid watches in the watch window at that time so I did not think that section was really relevant. Are you saying this section points to an error in my code that might throw off gdb or are you saying this could point to an other issue with gdb?
tigerbeard:
--- Quote from: nanalyly on February 14, 2023, 08:22:57 am ---Thanks
--- End quote ---
thanks for bringing this up again. I noted that I missed to given an update.
I was able to upgrade to newer version of gdb on Xubuntu 18.04 as suggested but the situation did not really change.
In the mean time I have moved to Xubuntu 22.04 since a couple of month and are on the newest GDB and toolchain:
GCC 11.2.0,
gdb 12.0.90
I use a CodeBlocks nighty r12864 trunc from August 30, 2022. The change logs do not show changes to the debugger plugin since then so I guess it would be the same than with the current trunc. I compiled CB against wx3.0 from the repository.
I kind of live with the gdb situation but its not really nice and it has not really improved. I am using the setup on multiple computers.
Usually I am running multi-threaded code >120,000 LOC, using wxWidgets, I observe
* once gdb halted on a breakpoint not set during runtime, it always halts there. I can deactivate the red disk but thats ignored by gdb
* the first time gdb stops it does not show a call stack. That means if the program crashes or offers to stop at an assert window thats useless because the strack is missing. Single step after that usually gives a gdb handup I need to resolve with kill. Better workaround is to stop at a known good place before, then continue and then it will give you the call stack and allows to see the cause of the problem.
* setting a breakpoint at runtime and removing it sometimes works, sometimes the removed breakpoint is ignored. I have not yet found a clear rule to follow.
* gdb regulary hangs. It freezes the Application and CodeBlocks. When killing the gdb process CB is responsive again. I have not fix found rules when it happens, but I tend observe it more on first breakpoint and shut-down issues, more rarely when stepping through code. When I am fulltime coding this happens about 10-20x per week.
* in 22.04 gdb seems quite slow, i.e. slower than stepping the same code in a 18.04 installation using the same code blocks but 8.1. gdb. When there are watch variables (e.g. >10, or a struct with it) I had sometimes to wait 3-4seconds per step.
The slowness issuse points to a spoiled 22.04 installation, but I have found no hints. First I suspeced slow file access, but the disk benchmark was similar to the 18.04 installation. I see that the nemo - RabbitVCS plugin only appears in the context menu on overy 2nd right mouse click which I a bit peculiar, but not enough to suspect a broken install. No other aspects seem strange.
Currently I can live with the workarounds. So I am more looking to learn if other Linux users see similar issues.
Thans
sodev:
Don't feed the spam bot...
tigerbeard:
--- Quote from: sodev on February 14, 2023, 05:05:21 pm ---Don't feed the spam bot...
--- End quote ---
????
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version