Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is...

[Cyclone]

Hi,

I am getting an error when I run my program.

the error is...

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often indication that other memory is corrupt.

I did some research and it seems this code is the problem.

// Create the Bitplanes
int* Bitplane0__ROW = new int[1000];
int* Bitplane1__ROW = new int[1000];
int* Bitplane2__ROW = new int[1000];
int* Bitplane3__ROW = new int[1000];

if I lower the values it runs without errors but not with the above values.

My program creates png images from those Bitplanes which are read from a file.

I tried to simplify my code to pin point the problem code.

I am expecting to write a 256 x 256 png image using the color data stored in those bitplanes.

Thanks in advance.

[Peter87]

Use a debugger to see which line of code where the access violation is happening.

[seeplus]

The error message doesn't seem to be for C++. What language/compiler are you using? Is this C++/cli?

If it works Ok when the size of the arrays are lowered, it could be that you are exceeding the stack size. Where in the program are these arrays defined? Try making them global at the top of the program.

[Peter87]

@seeplus Dynamically allocated arrays are not stored on the stack.

I'm not sure the problem has anything at all to do with the arrays. Maybe something else is at fault and a change in array size just happens to trigger an access violation because things are laid out differently in memory. Using valgrind or an address sanitizer might help.

[salem c]

You have to check all the prior memory allocations in your program to make sure you're not overflowing / underflowing / use after free / double free / etc.

int *p = new int[10];
p[10] = 0;  // oops 

The time it takes for this to show up as an issue can be anywhere between microseconds and years.

And it will usually manifest itself as tanking some completely unrelated code such as

int* Bitplane0__ROW = new int[1000];

> This is often indication that other memory is corrupt.
Exactly.

You need to look back through your code execution path that led to this point in the code, and see if you're doing anything suspect with any dynamically allocated memory.

[seeplus]

@seeplus Dynamically allocated arrays are not stored on the stack.

Whops! You are quite right. I think I'll chalk that down to 'having a senior moment'!

[Cyclone]

Thanks everyone for your replies!

Stack overflow suggest this below code.
I no longer get any errors but I have one other issue that breaks the program... :(

     // Create the Bitplanes
    //int* Bitplane0__ROW = new int[1000];
    //int* Bitplane1__ROW = new int[1000];
    //int* Bitplane2__ROW = new int[1000];
    //int* Bitplane3__ROW = new int[1000];

// This works
    std::vector<int> Bitplane0__ROW(10000);
    std::vector<int> Bitplane1__ROW(10000);
    std::vector<int> Bitplane2__ROW(10000);
    std::vector<int> Bitplane3__ROW(10000);

 if (p > 119 && p < 128) //  
            {
                // This Works
               // x_coord = 0x86 * 4;
               // y_coord = 0x80; 

                
                char oDataL[0x100]; // Sprite buffer
                ifstream inFileL;
                inFileL.open("C:\\Users\\Chris\\Desktop\\file.bin", ios::binary); // Note. this opens a binary streem. This is needed. cuzz the program was using 0x1a values as a Substitute AscII charter which halts the program/Using it as End Of File.
                inFileL.seekg(0xE48A1, 1); // Seek to the current sprite coordinate location.
                inFileL.read(oDataL, 0x100);
                inFileL.close();

// this does not.
                x_coord = oDataL[1] *4; 
                y_coord = oDataL[2]; 


            }

The idea is I read tiles from a file and read each tiles location.
If I manually specify the X/Y location it works but not when I read the bytes from the file.
Some byes work but others do not.

The bytes in question are...

0x86

and

0x80

for some reason they aren't reading correctly

[DizzyDon]

Try unsigned char, maybe you're getting negative values when > 0x79.

unsigned char oDataL[0x100];

You might have to cast oDataL to char in the read:

inFileL.read((char*)oDataL, 0x100);

[Cyclone]

Awesome thanks Dude! That did the trick!
So I was getting negative values then?
I would never had figured it out on my own. :'(

btw there is a typo in your example.... forgot the "*". ;)


Below code now works.

if (p > 119 && p < 128) //  
            {
               
                unsigned char oDataL[0x100];

                // Sprite buffer
                ifstream inFileL;
                inFileL.open("C:\\Users\\Chris\\Desktop\\file.bin", ios::binary); // Note. this opens a binary streem. This is needed. cuzz the program was using 0x1a values as a Substitute AscII charter which halts the program/Using it as End Of File.
                inFileL.seekg(0xE48A1, 1); // Seek to the current sprite header location.
                inFileL.read((char*)oDataL, 0x100);
                inFileL.close();

                x_coord = oDataL[1] *4; 
                y_coord = oDataL[2]; 


            }

[salem c]

> // This works

No, you rearranged the deckchairs on the Titanic.

All you did was change the order and layout of all the memory allocations in the pool, such to avoid whatever is currently wrong with the pool.

You didn't make the iceberg go away.
You just found a chair to sit in for the moment where you can't see it.

Basically, every new change you make to the code is rolling the dice as to whether the problem will come back.

[Cyclone]

Ah I see. That makes sense. Sorry I'm a noob.

What do you suggest I do so I can better understand the code?

My guess is that your jpg imaga has WAY MORE pixels than a 1000. So calculate the amount of memory before you allocate your memory (make your vectors). So show more of your code because the problem is not directly in here, but where you access the pixels. Side note you're probably better of not allocate memory for each single line, allocate memory for the whole plane (and calculate offsets in that yourself)

Thanks.

[George PlusPlus]

Stack overflow suggest this

Using a dynamic container, a vector, instead of a fixed sized array is a good idea for a couple of reasons. A vector automatically manages the memory used.

If you are going to use a vector you could instantiate one without any preallocated elements and push back what you read from the file on demand. So you don't need to know how many planes/pixels get read, the vector grows as needed on demand.

https://en.cppreference.com/w/cpp/container/vector/vector
https://en.cppreference.com/w/cpp/container/vector/push_back

Your vector automatically knows what its size is, it could be less or greater than your expected 1000 elements.

With a vector there are two ways to access an element. operator[] and the at member function. The at member function is a bit slower than operator[] because at performs bounds checking.

https://en.cppreference.com/w/cpp/container/vector/at

One (minor) drawback from not preallocating a vector's size on creation is the process of adding elements is slower than assigning elements in a presized vector. But not horrendously slower and expensive.

[Cyclone]

Hi, George.

Thank you for your guidance.
I will review the links you provided.

[George PlusPlus]

For the basics on fixed and dynamic containers there's 2 lessons at Learn C++ you might want to peruse. Chapter 16 for dynamic containers (std::vector) and chapter 17 for fixed size arrays (std::array and C-style arrays)

https://www.learncpp.com/cpp-tutorial/introduction-to-containers-and-arrays/

https://www.learncpp.com/cpp-tutorial/introduction-to-stdarray/

The rest of Learn C++ might be a good refresher for other parts of the language as well.

[Cyclone]

so salem c is correct. The problem came back. It seems a bit random, some times when i change the code the error message comes back. other times it goes away.

Would it help if I link to the code. Its quite long and inefficient.

thanks.

[George PlusPlus]

If you are using manual memory management then problems such as you are experiencing are gonna happen from time to time. It is the nature of the beast. Especially if you throw the pointer(s) around between and betwixt functions. Now it works, next time it might not, and ring around the collar again and again

With smart pointers or a container like a vector you can still clobber memory, it just takes a lot more work to mangle things up..

Fair warning... the actual problem could be in an entirely different section of code that happens to glom onto memory as well.

The only sure way to know where the problem(s) lie is to debug your code, preferably doing line by line execution examining memory as you go.

Would it help if I link to the code. Its quite long and inefficient.

Not to put too fine a point on it but you are trying to replicate what has already been done. There are libraries for reading, writing and manipulating image data. For PNG here's a meta-search for libraries you could use:

https://duckduckgo.com/?t=ffab&q=png+library+c%2B%2B&ia=web

Looking at the guts of an already created library could a great learning experience for the how-tos and possible pitfalls you might encounter crufting you own solutions.

[George PlusPlus]

FYI, if you are going to continue looking for help with this thorny problem here you might want to UN-check the topic's status.

[Cyclone]

^ I am trying to make a mod for a game so I am writing code from scratch.

Any ideas? Should I ignore the error message and use a TRY CATCH function?
The program seems to write the png files properly... despite the error

[George PlusPlus]

Any ideas?

Got lots of ideas, you've already been offered several by more than one person.

Should I ignore the error message and use a TRY CATCH function?

I refer you back to the first reply:

Peter87 wrote:

Use a debugger to see which line of code where the access violation is happening.

Never ignore error messages, either compile or run-time. Your code is doing something rather dangerous, even if only intermittently. System access violations (reading/writing memory your program doesn't own) is always a bad sign.

You should write code that is as warning free as possible as well. More often than not warnings can develop into errors that become hard to get rid of.

Even with code that seemingly works without errors using a debugger to step through your code is never a bad idea. Get used to debugging code, issues can show up before they become major errors.

FYI, nothing has really changed with your problem, you just keep moving things around to fix a problem that should be profiled and properly debugged.

Your memory problems might be in an entirely different section of your code, waiting to strike like a poisonous snake at a later time.

The program seems to write the png files properly... despite the error

"Seems to work" is the operative phrase. The files may be subtly corrupted, one or a few bits are not correct, and you'll never know it until *BOOM!* Your mod screws up the game files and the game ceases to work, or some other nasty and unwanted action.

I am trying to make a mod for a game....

A goal that I can understand and applaud. :)

...so I am writing code from scratch.

Been there, done that, and usually have fallen flat on my (digital) face more times than I care to mention or like.

My suggestion of looking at a 3rd party PNG library was for guidance. The authors of the libraries more than likely went through the same trial and error process and figured out how to do the work of PNG grunt work without having errors.

You don't have to use the library, study the code for pointers. The library code is likely doing things in a way you never even considered.

I don't know what your OS or your compiler is. The MS Visual Studio IDE has a good debugger built into the IDE. Running code in debug mode is always useful, especially with code that has errors. Setting checkpoints to halt execution and then step through you code execution allows you to inspect variables so you can determine if they are correct at the time.

Learning to use a debugger, and use it well, is never really emphasized in programming classes AFAIK or in books or online resources.

Would it help if I link to the code. Its quite long and inefficient.

Two points you should look at:

http://www.gregcons.com/KateBlog/HowToAskForCCodingHelp.aspx

http://www.sscce.org/ (Short, Self Contained, Correct (Compilable), Example)

Both of those links should be required reading for people looking for help.

What you consider long might be code I consider rather short and lean. Same with inefficient.

Expecting people to look at code that is more than a few dozen lines, and debug it for your for free, is asking a lot.

And the level of competence you get from others might be less than helpful. I am at the core a self-taught programming hobbyist with large gaps in understanding C++. There are times even with code I write I can't understand what it's doing after time has passed. I'm not even an "expert beginner".

https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/

With all that blathering above I've said all I should. I can only make a further mess of it if I don't stop.