Explicitly Initialize Dword to 1, But Debugger Shows Wildly Out of Range Value

Explicitly initialize DWORD to 1, but debugger shows wildly out of range value

Your code is more than likely optimized. This means that the compiler has moved and eliminated code in a way that your source code does not match what the compiler has produced.

Either debug unoptimized code, or debug optimized code with the full knowledge that the source may not match the actual instructions being performed.

If you want to debug a release build but see the correct values in the debugger, go to the Properties of your project in Visual Studio, go to the C/C++ section, and disable the optimizations. Rebuild.

How can Visual Studio C++ debugger be showing values of local variables that are at odds with another frame?

Turns out the comments on the question gave me the right clue here:

The bottom line is that you cannot simply debug optimized code, and expect the debugger to adjust itself to the optimizations done by the compiler.

When I debugged using a non-optimized build of UE5, I quickly saw the issue, and the CurrentStatus.State.Index is in fact 65533.

In case others run into this, it's not enough to use the "DebugGame Editor" config in the Visual Studio project for your game. That config only compiles your game's code without optimizations, the engine is still run using optimized code.

To run the engine without optimized code, you need to build it from source and use the "Debug Editor" Visual Studio config to disable optimizations. Then you can run your game by changing the path of the UE exe it uses in the Visual Studio project of your game from the project Property Pages under the Debugging section.

Getting Bad Ptr and invalid values when assigning values to CString

As Igor Tandetnik stated, my PDB file (the debugging information) was stale. Although I was receiving invalid debugging values, they were actually correct.

This was fixed by going to build -> Rebuild Solution.

Printing out DWORD in hex returns 0x7FFFFFFF in win32 c++

The strtol function returns a signed long integer, which on windows has a range of -2,147,483,648 to 2,147,483,647.

If strtol detects that the number generated is out of range, it will return the maximum long value. From cppreference:

If the converted value falls out of range of corresponding return
type, a range error occurs (setting errno to ERANGE) and LONG_MAX,
LONG_MIN, LLONG_MAX or LLONG_MIN is returned.

Use std::strtoul instead.

Visual Studio doesn't recognize boolean as variable

"I was accidentally compiling in max liability mode. I changed to Release to Debug and it works. Thanks!"

Glad to know that you have resolved this issue. But I agree with PaulMcKenzie's suggestion, the real issue would be related to certain settings during two different mode which couldn't generate the debugging informaiton.

(1The linker setting which will generate debugging information.
(2)Disable the optimizations option.

A reference about the similar issue:

http://www.databasesql.info/article/896010299/

how to search a QString in QVector

The problem

The iterator not being accessible, probably means the iterator points to the end of the vector, i.e. the element is not being found in the vector.

The solution

The problem is that std::find, searches an exact match, i.e. it uses the QString::operator == (const char *) (see Comparing strings).

You are looking for a string which starts with "2-". Therefore you have to specify a custom equality check, using std::find_if and f.ex. a lambda function:

QVector<QString>::iterator it = std::find_if(logMessages.begin(), logMessages.end(), [](const QString& s){
  return s.startsWith("2-"); // check if the element starts with "2-"
});

Performance consideration

Note that using std::find_if is slow (for large arrays) as it has O(N) performance. Using a QHash<int /*id*/, QString /*message*/> structure may improve your lookup performance.

---

Related Topics