In a debugging session, when I remove a breakpoint from the editor the breakpoint is not removed from GDB. To continue my work I have two options: Remove the breakpoint manually from GDB or open a new debugging session.
Setting the breakpoints works, the problem occurs only on removing or disabling.
I've already tried Code::Blocks version 13.12 and svn rev. 10253, 10314 and 10320.
Dell XPS 8300
Xubuntu 15.04 (Vivid) - Linux lucasggxps 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
GDB 7.9 (I've already tried 7.8.2)
Can you post the full debugger's log?
Can you reproduce this problem with a simple project?
This bug affects all projects.
The problem occurs because the GDB output uses another language depending on locale settings.
I have changed the system language to English and now I can remove and disable breakpoints!
To reproduce you need to change your system language (locale) to Brazilian Portuguese (remember that I'm running on a Linux distribution). On Code::Blocks, set the breakpoint on some loop and then start the debugging session. Once started the debugging session, you need to remove the breakpoint and see that the debugger continues stopping at the line.
Last edit: Lucas Guimarães 2015-06-06
Issue affects me as well, this is what i can provide:
Code::Blocks 16.01, Ubuntu 12.04 64 bit
default environment for tests:
LANG="de_DE.UTF-8"
LANGUAGE="de:en"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
"toggle breakpoint" every 2nd time adds NEW breakpoint, every time with message "Haltepunkt %u at %p: file %s, line %u", breakpoint number incremented ("Haltepunkt" = breakpoint)
otherwise no message, no change to breakpoints
debugger console: "info breakpoints" confirms that
after a couple of toggling, you end up with multiple same breakpoints
"remove all breakpoints" does nothing, "info breakpoints" confirms that
now only changing LANGUAGE does this:
LANGUAGE="de_DE.UTF-8":
same behaviour as "de:en"
LANGUAGE="en_US.UTF-8":
behaviour as intended:
"toggle breakpoint" adds new breakpoint, without message - or deletes the correct breakpoint without message
"remove all breakpoints" removes all breakpoints except #1 "exception throw", without message
This is from a forum post about this issue. The log covers a Breakpoint set in CB but not removed in gdb. The GUI side, both Editor and BP Window work consistently (all BPs I added or removed in the editor are added or removed in the BP window). Only the gdb side gdb differs. I included "<======" where I think the key points are. I can not attach the program and I did not manage to reproduce it with something small yet.
The trace action was:
The BP from the test was BP6. The trace shows hitting it twice (which is OK). Deleteing it, however, deletes BP5. The BP Windows still shows BP5. When dbg continues it still has BP6 and of course stops there. When the BP is added in the editor again, it added "over" the first one, generating the last message.
The trace shows a precularity with two BPs when they are initially set, an additional ">>>>>>cb_gdb:". Maybe meaningless.
GDB 8.1 is known to have issues and a such is NOT a good to test on.
I debugged the issue and I think I have found the root cause.
Its in the DebuggerGDB's Option for User Init commands. This causes the above simple procedure to sometimes work or fail.
To reproduce just add two two lines in the Options Init box (e.g. the following two lines) and the test will fail in any project with the first breakpoint set before the debugger is started. It can not be removed any more while the debugee runs, because its index in CB is -1. The GDB index is different.
The reason is that the parsing GDB replies fails at the breakpoints when more than one init line is entered.
This is what happens: The two commands above will be sent as a single GDB command in the function
where "init" is a string containing both lines entered into the text control above.
It looks that these commands are queued together with all other initialization commands into the gdb command queue. After the queue is run, its expected that gdb completes the commands in the same order and sends replies for each. Thus the replies are parsed and assigned to the commands in the original order.
The problem with the breakpoints is that gdb addresses them by index, but the index is returned only via the command output. When the parsing fails the index remains at -1 (invalid) and thus GDB will not recognize this breakpoint index and a delete command will fail.
For the breakpoint the parsed line is processed by
The cmd calls the following function which eventually sets the correct breakpoint index.
Trouble starts when GDB returns more lines to parse then commands were sent. This gets worse the more lines are added in the init option box. GDB seems to understand multiple commands per line, but it does not return mutltiple returns in one line.
In my test case with 2 line the "CurrentCommand()" started with 16 initial GDB commands but got 17 replies. Thus the reply for the Breakpoint line was parsed by the gdb "run" which was following the original break command.
I can not see how the design is supposed to handle the replies to the user gdb init commands, maybe I overlooked something. Those commands were never parsed (only macro resolution is done). That means he debugger plugin does not know how many line there are and what commands are added by the user.
The obvious workaround is to never use more than a single init command.
I do not want to mess with a design I do not fully understand. But maybe a multiline text control could be a way to get a line count, insert some dummy commands to get the "QeueueCommand() - ParseOutput()" balanced.
I do not really understand why the init lines must be sent in one go, but looking at some of the omments it seems to me that some people may do some quite sophisitcated stuff whith these init commands that is way over my head.
Hopefully this insight is useful to reproduce and resolve the issue.
Last edit: Tiger Beard 2024-01-13
Based on the proposal above I have implemented the test code below.
The fix finds out how many init command line the user has added and adds for the surplus lines the dummy command "userInit". That should balance out with the GDB Parsing replies.
The code does what it should but the results are not stable. When using multiple Breakpoints with multiple debugger starts, sometimes there is still a -1 index in there. I saw that the "ouput" string to parse sometimes contained 2 GDB prompts instead of one - maybe a timing issue on my compulter.
However, its a definitive improvement so I will use this for my local version. Maybe its useful for further analysis.