BUG: visual studio or .net framework?
ok, this is driving me crazy. it only happens in 2003 (I cant reprduce it in 2005)
can sombody debug this in 2003 and let me know what happens:
- create a console app
- paste in the following code in your main:
Code:
string s = "abcdefghijkLMNOPQRSTUVWX";
byte[] b = System.Text.Encoding.UTF8.GetBytes(s);
Console.ReadLine();
- set a break point on the last line.
- start in debug mode (let it hit the breakpoint)
- bring up the memory window (CTRL+ALT+M, 1) and types in the address box (1)
- highlightSystem.Text.Encoding.UTF8.GetBytes(s) and bring it up in the quick watch window (2)
What happens for me:
- Shows unknown location (all ? marks)
- shows a 25 byte array starting w/ [0] = 24, [1] = 0, [2] = what [0] should have, and from this point on, its the original truncated byte[]
if I follow these exact same steps in 2005 I get what i'd expect, where 1 shows the memory contents of s, and 2 shows the encoded (24 byte string) of s.
in 2003 if I pin s:
Code:
string s = "abcdefghijkLMNOPQRSTUVWX";
GCHandle sh = GCHandle.Alloc(s, GCHandleType.Pinned);
IntPtr sp = sh.AddrOfPinnedObject();
then type sp into the address box of the memory window I get what I'd expect to get by typing in s.
anybody else get anything different (post what you see)?
I don't have VS2003 installed, so I can't actually perform those steps, but I'm pretty sure what's happening.
The code itself is correct. What you are seeing is a quirk of the debugger. You'll note that in neither of you examples, is there any reason for the varaible s to exist they could have just as easily have been written as:
byte[] b = System.Text.Encoding.UTF8.GetBytes("abcdefghijkLMNOPQRSTUVWX");
Console.ReadLine();
And that, most likely, is how the compiler coded it, eliminating s in the process. No "s", nothing to display in the memory window. (It could very well have eliminated b[] in the same way.
Now, if we were to do something to force s to exist as a variable, we'd probably see what we want:
static void Main()
{
DoIt("abcdefghijkLMNOPQRSTUVWX");
}
private void DoIt(string s)
{
byte[] b = System.Text.Encoding.UTF8.GetBytes(s);
Console.ReadLine();
}
nope, it doesnt eliminate s. I can see it stored in the registers (and can pin it w/ the same result).
The reason for this test is that I have a bug in an application I'm working on. we store a utf8 encoded string in a database. that string converts (or is supposed to anyway) to a 192 bit key for 3des encription. the key is encoded by the client and entered into (through the app) our database. the exact steps to UTF8 Decode the key string are represented in example I posted.
when we pull the string from the database, and call UTF8.GetBytes only to end up w/ a 25 byte array (instead of a 24 byte array), which obviously throws an exception in the 3DES encryption.
trying to debug it, I ran across the problem and came up with the sample I posted. Reflector shows that the source code has changed between 1.1 and 2.0.
UTF8 is used far too often in .NET to be unstable. I cant figure out whats really going on, but I get a 25 byte array in production, and in my quick watch window. I guess the only thing left to do is to check my updates from this last patch tuesday to see if there is any .NET related updates that went out.
This totally doesnt make sense to me.
OK, now that I've seen them in vs2003, I attribute both to bugs in VS2003.
The missing s clearly does not involve the .Net framework, so it has to be a bug in the VS2003 (although one might argue that it's a "missing feature" that was added in vs2005)
The size being displayed as the first two items in the array might have been in the .Net framework, but as the value that end up in b[] is correct, it would seem that the bug is with QuckWatch. (And no way around that one -- it's a bug)
