5

When I'm debugging C++ mixed (managed/unmanaged) projects in Visual Studio 2005, I often get weird data from the debug watches, like below :
(btw, the variable i_processName is a const std::string & )

alt text http://img175.imageshack.us/img175/3561/43419953av1.jpg

Note that the variable actually holds valid data - if i print it to stdout, the printed string is just fine, thanks for asking. The simpler types of data (e.g. ints) (usually?) get their correct values shown.

Did this ever happen to you too?

This is a major PITA when debugging, so ... any ideas on how to make the watches show the correct data, or what's causing this?

Cristian Diaconescu
  • 34,633
  • 32
  • 143
  • 233

6 Answers6

1

I beleive that Aardvark is probably onto the correct answer. If i remember correctly when you are compiling mixed mode, the compiler will turn as much of the C++ code it can into code that runs on the CLR, and consequently memory that is owned by the CLR. My geuss is that the debugger is confused about where the string is held - unmanaged or managed memory.

Zac
  • 3,235
  • 4
  • 25
  • 30
1

Looks like your debugging symbols are incorrect.

Check the modules debug window (menu: Debug>Windows). Check that modules you are debugging have "Symbols loaded." listed under the Symbol Status column. Check that the Symbol File listed is the file you think it should be. You can right click a module and get more info about how VS loaded the symbols and you can reload them as well.

If you're having symbol loading problems you can set paths and other settings under Tools>Options>Debugging>Symbols.

A bad call stack can cause issues like this as well. Make sure the stack doesn't have any entries like "the stack may be incorrect for this point...". Does it?

It also can be something odd with Visual Studio confusing native and manged data types in the visualizer, but I doubt it. The popup in your screen shot looks like the debugger know what the variable is.

Aardvark
  • 8,474
  • 7
  • 46
  • 64
1

Debug display of custom types (this includes the STL) depends on the file autoexp.dat located in the <install_path>\Common7\Packages\Debugger folder. Make sure that yours matches your library version and that an older version of this file hasn't been kept around (when upgrading for example).

Note that you can also write your own visualizers for other types, more info here and here. This is a major time saver for complex projects, well worth the (small) effort put into writing custom visualizers.

fbonnet
  • 2,325
  • 14
  • 23
1

Yes, i see this problem in my debuger,
in my case its connected to Unicode vs NonUnicode.

Avram
  • 4,267
  • 33
  • 40
1

One thought -- the STLPort implementation of std::string uses a split buffer implementation. It has a small static buffer (I want to say 14 characters) and a pointer to a char array. One of these will be invalid and the other will contain the string data, depending on the length of the stored string. If you're using STLPort or a similar implementation, your string visualizer might be looking at the wrong buffer, which happens to contain junk data.

Tim Keating
  • 6,443
  • 4
  • 47
  • 53
0

This is a bug that has been in the Visual Studio debugger since forever and still occurs in Visual Studio 2019.

It is random.

Sometimes making a code change and recompiling resolves the problem, and sometimes it doesn't.

Florian Winter
  • 4,750
  • 1
  • 44
  • 69