Different _fileName values in Visual Studio debug watch

Question

std::string filename;

In this code:osg::Image* image = osgDB::readImageFile(filename + ".dicom");

osg::Image type variable: image gets wrong returned values from read file. And by debugging to the line above, the watch window shows as follows: enter image description here

The _fileName (std::string type) value indicated on the first and second lines are both "digest", but in the fourth line the value of _fileName turned out to be "iiiiii\x*6" with capacity equals to 0.

According to my understanding, the _fileName of the fourth line in the watch window should indicate the same member variable of osg::Image as the _fileName on the first and second lines. Thus, I think all the _fileName in the debug watch window should have the same value. But, I am not sure why there are such differences.

It looks like there are two members named _fileName in two separate classes. — n. m. could be an AI, Dec 04 '14 at 06:21
if `filename` (as a parameter to function `readImageFile`) is `char *` then you're trying to add two pointers (`filename` and `".dicom"`), and if so, the result could be undefined — borisbn, Dec 04 '14 at 06:54

score 1 · Answer 1 · answered Dec 11 '14 at 18:39

For some reason your filename argument isn't getting .dicom attached to it when it becomes _filename ("digest" should become "digest.dicom"). OSG decides which plugin to use for file loading by extension, so it will have no idea how to load the current one. And so the second reference to _filename doesn't get intialized by any plugin.

By the way, I don't think the dicom plugin is part of the standard OSG prebuilt package - you might have to gather the dependencies yourself and build the plugin.

AnT stands with Russia · Accepted Answer · 2014-12-11T18:59:58.307

MSVC++ implementation of std::string uses different storage strategies for short strings and for long ones. Short strings (16 bytes or less) are stored in a buffer embedded directly inside the std::string object (you will see it as _Bx._Buf in Raw View). Long strings are stored in an independently-allocated block of memory located elsewhere (pointed by _Bx._Ptr).

If you violate the integrity of std::string object, you might easily end up in a situation as the one you describe. The objects thinks that the data should be stored in the external buffer, but in reality it is stored in the internal one and vice-versa. That might easily confuse the debugger as well.

I suggest you open the Raw View of your std::string object and check what it shows in _Bx._Buf and _Bx._Ptr. If the current _Myres value is smaller or equal to the internal buffer size, then the data is [supposed to be] stored in the internal buffer. Otherwise, it is stored in the external memory block. See if this invariant really holds. If it doesn't, then there's your problem. Then you'll just have to find at which point it got broken.

Different _fileName values in Visual Studio debug watch

2 Answers2