Community
Participate
Working Groups
Steps to reproduce: 1) Create a new C++ "Hello World" executable project 2) Put a breakpoint on the line with return 0 3) Set its condition to: !strcmp("a","a") 4) Start project in debug mode Expected result: Program halts on that line. Actual result: Program doesn't halt, gdb traces shows the following output: 838,175 16-break-insert --thread-group i1 -c !strcmp(\"a\",\"a\") -f /home/dries/workspace/quotes-bug/src/quotes-bug.cpp:14 838,187 16^error,msg="Invalid character '\\' in expression." --- Interestingly enough, if you change the condition to 0 == strcmp("a","a"), the expression is correctly wrapped in quotes, so the \" properly escape.
This problem basically blocks me from using conditional breakpoint with strcmp(), which was very handy. If I use the condition 0 == strcmp("a","a"), it adds double-quotes to enclose the expression automatically, and it becomes "0 == strcmp(\"a\",\"a\")", which is correct. Looks like the tool knows something about the input expression, so maybe it can do something more. But, I think it would be better that the tool just copy&paste the expression into gdb command line without manipulation.
BTW, I found a simple workaround: adding a redundant whitespace in the expression. I can set !strcmp("a", "a") as the expression (note the space after comma), and then the tool adds double-quotes automatically, making the backslashes correct.
This WA doesn't work now.
It's tricky to figure out exactly what GDB is expecting as escape characters and quotes in different situations. It is particularly difficult when trying to support GDB versions ranging from 7.1 to 7.9. This makes me very hesitant at changing the current quotation rules if we have a workaround. I tried the workaround of adding a space and it still works for me. So the following works: !strcmp("a", "a") 0 == strcmp("a","a") I believe with this, one can use strcmp in conditions to its full potential. Bing-Yi, if the workaround still does not work for you with CDT 8.7 and GDB 7.9, can you provide the steps as to how to reproduce?
Hi Marc, sorry I didn't notice you've replied here. I think the step in the original description is good enough. (1) Create a C++ "Hello World" project. (2) *Before launching*, put a breakpoint on the line with cout. (3) Set its condition to strcmp("a", "b"). In breakpoints view, observe the breakpoint has [condition: strcmp("a", "b")]. That is correct. (4) Now launch it. The program breaks on the line. Observe the breakpoint now becomes [condition: strcmp(\]. (5) Launch it again. This time the breakpoint doesn't work. And here is another flow to reproduce: (1) Create a C++ "Hello World" project. (2) Set a normal breakpoint on the line with cout. (3) Launch and break on that line. (4) Set a conditional breakpoint on the next line. Observe the breakpoint has [condition: strcmp("a", "b")]. (5) Continue and hit the breakpoint. Now, observe the breakpoint becomes [condition: strcmp(\]. Put both experiments together, I suspect something wrong happens when the conditional breakpoint is hit. The breakpoint surely works but only once. In reality, that is totally useless. Version info: CBT 8.7.0 GDB 7.6.2
*** Bug 471997 has been marked as a duplicate of this bug. ***
It seems the breakpoint can be hit multiple times during one execution but gets changed upon exiting of the debugged executable. I guess some issue with re-loading in the breakpoint conditions after they have been escaped?
