Memory window adress bug

[Blutti]

Dear reader,

In the memory window VisualGDB displays the currently highlighted byte in the following (very useful) way:
“Current address: 0x20000A8A (exampleNamespace::exampleVariable + 0xNN)” (where exampleNamespace:: is only displayed if it is not globally defined, which is nice; and where NN is the index from the base)
So if you were selecting the 8th byte in an array it would say “exampleVariable + 0x08” which is fine.
This N value however, is decimal while it claims it is hexadecimal (0x prefixed). So if you were selecting the 10th byte of an array it says “exampleVariable + 0x10”. When it should say “exampleVariable + 0x0A” or “exampleVariable + 10”.
This is a small oversight/bug but it is be extremely confusing.

And as a side note; the memory window only seems to show this detailed address (the “(exampleVariable + 0xNN)” part) when the variable is declared static/globally. So local/automatic variables don’t get this description.
I’m guessing this is because they are stored on the stack which is treated as one big array of memory (and is labelled in the memory window as Frame #N (<function name>) which overrides/clashes with this functionality. But it would be nice if these variables would also get this feature.

With kind regards,
Blutti

[support]

Hi,

Thanks, the +0x10 is indeed a bug on our side. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.16.1458.msi

Regarding the local variables, it could be quite time-consuming to query their ranges from gdb, so we don’t currently do it. We will re-investigate this in v5.3 and will consider adding an option to do that.

[Author]

Posts