Unsolved QtCreator debugger showing (invalid)?
-
I am debugging an application and when I single step:
QDateTime dtmCreated(QDateTime::fromString(strValue, Qt::ISODateWithMs)); if ( dtmCreated.isValid() == true ) { rdtmCreated = dtmCreated; qDebug() << "dtmCreate.isValid: " << dtmCreated.isValid(); }
The output is:
2021-10-12T07:36:14
The debugger shows:
dtmCreated (invalid)
However it clearly isn't invalid as the call to isValid returns true and the console output displays the date, so what is going on?
I'm using Qt Creator version 4.4.1 Based on Qt 5.9.2 (MSVC 2015, 32bit) Built on Oct 4 2017 04:12:53.
I have no choice on the version I'm using, the hardware and software is provided by the client I am contracting to. Is this a known bug?
-
@SPlatten
Whatever it is, I would have thought it is an MSVC compiler/debugger issue, not a Qt Creator one.I always find occasionally a debugger shows this sort of thing due to code generation/optimization details. Since you say the program behaves correctly I wouldn't worry about it. If you absolutely have to know and the debugger is not playing ball, try temporarily passing it as a parameter to another tiny function and look at value there, that usually forces code/debugger to sort itself out.
-
@SPlatten said in QtCreator debugger showing (invalid)?:
qDebug() << "dtmCreate.isValid: " << dtmCreated.isValid();
Try std output to see if it is the same:
std::cout << "dtmCreate.isValid: " << dtmCreated.isValid() << std::endl; -
@SPlatten said in QtCreator debugger showing (invalid)?:
However it clearly isn't invalid as the call to isValid returns true and the console output displays the date, so what is going on?
Your code snippet does not output the date, so its unclear what code you are running/debugging.
-
@JoeCFD , the output can only be performed if isValid is returning true.
-
-
@jsulm , I didn't post that line, but its simply:
qDebug() << dtmCreated;
-
@SPlatten said in QtCreator debugger showing (invalid)?:
dtmCreated (invalid)
sadly not unusual. That happens when the debugger/the python interface can't really dissolve the code.
Happens frequently if you're for example inside a lambda body, deep inside nested classes or compiled with optimisation levels != O0
-
The debugger behavior is a frequent issue, which results from trading speed for accuracy: the variable‘s display is initialized at an earlier point of time when the variable itself was uninitialized. Forcing all displays to be always current would slow down your debugger. Creating a small submethod and calling it with the variable in question as explained by @JonB usually forces correct displays if you really need it.