Thread: Memory anomaly

Hi guys, I've got this problem that's driving me nuts:

I've got this code:

Code:

	unsigned char memory_content[112];
	ZeroMemory(memory_content, sizeof(memory_content));
	//TEST DEBUG
	memory_content[0] = 'A';
	//END TEST DEBUG

When I traced step-by-step in the debug and right after the ZeroMemory function, I see that the 4 first value in 'memory_content' is not zeroed like the rest. And then in the TEST DEBUG line, the one that got changed was the 'memory_content[4]' one not the 'memory_content[0]'. So it was like this:

1st line: memory_content[0] until [111] = garbage chars.
2nd line: memory_content[0] until [3] = garbage chars, [4] - [111] = 0
3rd line: memory_content[0] until [3] = 0, [4] = 'A', [5] - [111] = 0.

Now what the hell happened here? This is so bizarre. Can anybody help me please? Thanks a lot in advance.

Have you tried rebuild all?

Why bother with ZeroMemory() in that code?
Just use zero initialization:

Code:

unsigned char memory_content[112] = {0};

and get rid of the call the ZeroMemory().

Originally Posted by cpjust

Why bother with ZeroMemory() in that code?
Just use zero initialization:

Code:

unsigned char memory_content[112] = {0};

and get rid of the call the ZeroMemory().

Good suggestion.

I would, however, agree with vart, it is likely to be a mismatch between the object code generated by the compiler, the debug symbols and the source code. A rebuild should fix this type of mismatch.

--
Mats

Sorry I replied so late. Thanks guys. I've done a complete rebuild but it's still behave the same way. Maybe it's because I just copied the project to the solution. You see actually the one that has this error is a project that was from another programmer that I re-use. So I just copied the .vcproj file and all the source and headers.

[QUOTE]
Originally Posted by cpjust View Post
Why bother with ZeroMemory() in that code?
Just use zero initialization:
[/QOUTE]

well. let's see what ZeroMemory is doing:

Code:

#define RtlZeroMemory(Destination,Length) memset((Destination),0,(Length))

i think there is nothing wrong with it...

i tried your code... it s just fine...
are you debugging in release mode? make sure it is in debug mode... if you put breakpoint in release mode, and watch the parameter, it won't show correct result you know...

Originally Posted by auralius

i think there is nothing wrong with it...

It is not wrong, but it is unnecessary since zero initialisation will suffice and is certainly more portable.

If you add code to print out the actual values of the first few positions in the array, you'll find that your debugger is simply a little off. This happens from time to time in release builds, and I find it pretty common in post-mortem debugging. It's usually pretty good in debug builds, though posibly not infallible.

So, what should I do? Do I have to make a new project and add the sources & headers manually? Would that solve the problem? I mean, a complete clean build can't seem to solve it.

@auralius

AFAIK even if you add a breakpoint, it won't be triggered in release mode, so to answer that question, I was debugging in debug mode.

You could just either live with the fact that it's coming out wrong, or consider switching to a different version of Visual Studio. Which version are you on?

Originally Posted by iMalc

You could just either live with the fact that it's coming out wrong, or consider switching to a different version of Visual Studio. Which version are you on?

Well, I'm using VS 2005 Express. Maybe I would have to use a hack to solve this. Thanks a lot guys.

g4 -

You should provide more information than just the code snippet you are using, if you can. I think I have an answer as to what is happening.

There are two issues you brought up. The first is that the memory in the first 4 bytes is not being zeroed out with the rest of the memory. The second is that the letter 'A' appears to be saved into array[3] rather than array[0]. (Please correct me if this is not the case).

You should take a screenshot of your memory output in your debugger. Depending on the architecture of the machine which this is compiled/run on, memory isn't stored exactly as we may think it is. Per the architecture, memory can be saved in either Big-Endian or Little-Endian notation.

Little-Endian means that the bytes are stored with the least-significant byte in the lowest address of memory (somewhat "backwards" to what we would imagine). If you have declare a variable as such:

Code:

int var = 0x11223344

Then in memory, at the address of "var" you would see

Code:

&var: 0x44 0x33 0x22 0x11

When you set the first char (which is typically a single byte) as 'A', then in memory on a Little-endian architecture would look like this (assuming ASCII).

Code:

0x00 0x00 0x00 0x41

Big-endian is the opposite, where the most-significant byte is stored in lower memory address, and the previous example of 0x11223344 would look like this in memory

Code:

&var:  0x11 0x22 0x33 0x44

Most intel-based architectures are Little-endian, which would explain why it looks like when you set the zeroth element, that it is setting the 4th in the array.

As for why the first 4 bytes are not initialized, I would guess it is because the compiler used some sort of optimizations. Since machines typically deal with memory in chunks of their native capacity (32-bit architectures would use 32-bit chunks), the compiler determined that you were setting the first byte as something other than zero, but deals with the first 4 bytes in order to set it. Rather than clearing out that memory first (during the ZeroMemory), it left the first 32-bits alone and set them correctly after the initialization of the first byte. So rather than zero out the first four bytes, then have to run through and set the first byte (while also manipulating the 3rd-4th bytes), it skipped the first 4 bytes and set them properly when you set the first byte to 'A'.