Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Conditional breakpoints on QString value with GDB in Qt Creator.
LScott last edited by koahnig
The problem referred to in the linked post still seems to exist.
GDB/Creator gives no error about the condition, but for example:
QString test = "Test Value"; /*Breakpoint here*/ qDebug() << test; test = "Bananas"; /*Breakpoint here*/ qDebug() << test;
with both breakpoints having the following condition:
test == "Bananas"
In theory, the debugger should only break at the second breakpoint, however the condition seems to be ignored, and the debugger breaks at both breakpoints.
Conditional breakpoints seem to work just fine with primitive types. Am I missing something? This seems like a fairly essential debugging feature.
You might be right that the problem is a bug and still exists. However, the other post does not relate to an entry to the bug reporting tool JIRA which is the only valid place for bug reporting. The forums are not monitored for possible bug reports.
Did you check already on JIRA ?
You find an entry there, please check status and provide a comment there. Otherwise file a bug report.
Please also report the link to the bug report here.
JonB last edited by JonB
As a workaround, does the (GDB) condition accept a function call, say,
strcmp()or similar, or a cast, you could put up with? I'm not sure Qt Creator debugger is claiming to offer much over whatever GDB will accept?
LScott last edited by
strcmp("Bananas", test.toLatin1().data()) == 0
as the break condition works, with the exception that it will always break the first time the expression is evaluated, regardless of the result...
After further investigation, the original expression:
test == "Bananas"
Does in fact work, but exhibits the same behaviour, where the breakpoint will always be hit the first time, regardless of the result of the expression... Adding to the 'ignore' count doesn't seem to affect this...
Can anybody else replicate this behaviour? I feel like I must just be missing something obvious, otherwise this must indeed be a bug.
I have played a bit around with MinGW pre-build Qt 5.4.2 and recent Qt creator.
and the breakpoint pane
It stops always in all locations, but not in line 24 at all.
Please advise, if I am doing something completely different.
The breakpoints have been set with F9 and edited with this dialog
LScott last edited by
When I run the same code with the same breakpoints, it breaks every time any breakpoint is hit, regardless of the value of 'tst'.
The behaviour seems inconsistent - I got it to kind of work as described further up, but now it doesn't seem to work again...
For reference, I'm using g++ Qt 5.9.2 built from source on Debian 9.5 x32 i386, Qt Creator 4.4.82, also built from source (git).
For reference in my case it is Windows 10 64 bit. Creator is 4.7.0
I think you may want to check on JIRA as already suggested before. If nobody reports it, it will not be fixed. You reference this thread in the bug report and vice versa.
LScott last edited by LScott
OK, thanks. I have added a reference tothis thread. Let's see what happens.
The bug report has been closed already. Here the comment of the assignee:
1. QChar c; for(; c <= 'z'; ++c) does not compile.
2. What can be used in breakpoint conditioned is defined by what the underlying debugger (GDB here) is able to handle. It is not possible to have arbitrary C++ code there, specifically you cannot call functions that are not present in the binary, e.g. because they are inlined by the compiler or have not been used in the application code, so the linker had no reason to include it.
3. You can fiddle around with something along the lines of creating a breakpoint using gdb's python interface and a condition based on some translation of set $s = QString::toLatin1_helper(test) / set $p = $s.d.offset + (char)$s.d / strcmp($p, "d"), but that's not worth it as long as you can modify the code and put the condition in the code.*