Hi,
I am writting a program to open a binary file, take a 64-bit value at a time and modify some of the bits, then put it back into another file. Everything goes fine until the part were I try to store the 64-bit data in a (unsigned __int64*) buffer, it gives me an unhandled exception: 00xC0000005: Access Violation. And I really don't understand why.... I am using visual studio 6.0.

here's part of my code:


Thank you in advance!

You declare temp2, but never assign it a place to point...
Essentially it is pointing to NULL (non-space).
Try something like temp2 = &some_storage_location
At that point, when you dereference the variable to assign to its location, it will have a location to assign to.

Hi,
Thanks for your response, but now it seems like there is still a problem. I initialize the temp2 variable with the code below and made sure with the debugger that it has a location to point. The code runs fine until index = 57928(E248h) or 61440(F000h), then it gives another access violation exception. I don't understand why it crashes if at the initialization I specify the amount of memory needed. If you need more code than this let me know.

Here is how I initialize it:

Thanks

Make the program tell you what's wrong:

If you know that it crashes when you do this:


Then make the program tell you what's the value of temp2:


(Note that "cout<<" for pointers gives pointer values in hexadecimal.)

What is the maximum value that it can be before it runs beyond the end of allocated memory?

(I would recommend starting with a smaller buffer and a smaller file for test purposes.)

A couple of notes:

Since temp2 is a pointer to a 64-bit quantity: What happens when you add 1 to temp2? What happens when you add eight to it? (Print it out and you will see).

You don't ever test to see if the pointer is out of the range of the number of bytes that you allocated. This leads to the infamous "buffer overflow" problem that has been exploited by script kiddies and other miscreants over the years. This is a Bad Thing. Lucky people see their program crash while testing. Unlucky people release the program with a (hidden) bug that is later exploited.

You don't test the value returned from new. If you try to get a bigger and bigger buffer to try to keep it from overflowing, sooner or later you will ask for more memory than the system can give. Then the program will crash.

By setting temp2 to a new value each time through the loop, you have destroyed the value that you got from new, so you can't ever delete it. So the memory can't be returned to the operating system at the end of the program. This is called a "memory leak", and is a Bad Thing. Save the value so that you can "delete []" it later.


Regards,

Dave

Thank you for your response, it help a lot. I was adding 8 64-bit value addresses to the pointer instead of adding 1 address at a time. I have also added the delete[] operator to free the memory. Now that the buffer overflow is not happening do I still need to test for it? how can I do that?

Thanks

One possible approach for testing: First of all make sure that you can process each and every byte of a file (without encryption). Then try the encryption. I typically spend more time getting input and output correct than actually processing the data. I/O must be correct, and it's easier to test I/O if you don't scramble the data.

So, I would create a text file. I would temporarily defeat encrypting that the program is doing, so that the output should be exactly the same as the input.

I would try it with short files, but I would be sure to use files that have lengths that are all possible values modulo 8 (since you are reading 8 bytes at a time). I would make my buffer small enough that I could use reasonably sized files that are larger than the buffer.

[editorial]
Why, oh why would you think you need a buffer that is over 200 Megabytes long for a program that is processing data in 64-bit chunks????? Do you think that would improve performance? I doubt it but after getting everything to work with small files (and a buffer length of, say, 8), I might try it with a really big file with a really big buffer and time the results. In the meanwhile, trying to debug a program where my test case is a 200 Megabyte file is just unthinkable.
[/editorial]

Then, once I was sure my input and output are exactly and precisely correct, I would enable the encryption stuff. Again, start with some short text file.

Now you have an output file. How do you know it's correct? (How do you know what is correct?)

If this is some kind of encryption scheme (as I have assumed), I assume you have a decryption algorithm lined up and waiting to go. So, you use the decryption program to try to get the original text file back.

I don't see any restrictions that make this only work with text files, so you could use non-text input and output files, but by using text you can tell "at a glance" whether the basic flow gives correct results after decryption.

Of course, after a quick glance, you should check that the file length is exactly the same (dir for Windows, ls -l for Linux) as the original and use "fc" for Windows, or "diff" for Linux to verify that the contents of the original text file is exactly the same as the one obtained from decrypting the incrypted file. For a non-ascii input file, of course, use fc /b for Windows and cmp for Linux.

Regards,

Dave