Hey there, let's break down this confusing problem you're dealing with—when your vector iterator returns a User object, the values seem wrong, but GDB shows the object's fields are correct. Since you mentioned the loop code isn't the culprit, here are the most likely causes and fixes to check out:

Possible Causes & Fixes #

1. Missing const Qualifiers on Getter Functions #

Looking at your User class definition, the getName() and getPass() methods aren't marked as const. If you're using a const_iterator (or if the vector is const-qualified somewhere), calling non-const member functions on a const object is undefined behavior. This could lead to unexpected values when you call the getters, even though GDB can see the underlying member variables correctly.

Fix this by adding const to your getter declarations (and don't forget to make them public if you're calling them from outside the class):

class User {
    string password;
    string username;
public:
    string getName() const { return username; }
    string getPass() const { return password; }
    // ... other methods
};

2. Broken Copy Constructor #

When you dereference a vector iterator, you get a copy of the element (unless you're using references). If your User class has a custom copy constructor that doesn't properly copy the username and password fields, the copied object will have incorrect values—even though the original in the vector is fine (which is why GDB shows the right fields).

• If you don't have a custom copy constructor, the compiler-generated default one should handle string members correctly, so this isn't an issue.
• If you do have a custom copy constructor, double-check that it copies both fields:

  User(const User& other) : username(other.username), password(other.password) {
      // ... other member initializations
  }
  

3. Iterator Invalidation #

Even if your loop code is innocent, if the vector was modified (e.g., push_back, erase, resize) before or during iteration (maybe by another thread, or code you overlooked), the iterator could be invalidated. Dereferencing an invalid iterator leads to undefined behavior—sometimes it might seem to work, but return garbage values, while GDB might still show the original data by chance.

• Verify no code modifies the vector between when it's populated and when you iterate over it.
• If multi-threading is involved, ensure the vector is properly synchronized (e.g., using mutexes) during access.

4. Compiler Optimization Quirks #

If you're compiling with optimizations enabled (like -O2 or higher), the compiler might rearrange code or optimize away variables, leading to discrepancies between what you see in GDB and what the program actually executes.

• Try recompiling with optimizations turned off (-O0) and run your program again. If the values are correct now, the issue was likely due to optimization-related debug inconsistencies.

Quick Debugging Steps to Narrow It Down #

• Skip the getters temporarily: directly print the member variables from the iterator, like cout << it->username << endl. If this shows the correct value, the problem is definitely with your getter functions.
• Check if you're iterating over a copy of the vector instead of the original. For example, if you passed the vector by value to a function instead of by reference, you'd be iterating over a local copy that might have unexpected values.

内容的提问来源于stack exchange，提问作者Stephen Burns