Read of address 00000444

[AshishMishra]

Hi guys,

I am working on a project (abc) and encountered with an error "Access violation at address 00435C27 in module 'abc.exe'. Read of address 00000444". I tried to resolve it by clearing Desktop Memory, Restarted it and looked for solutions online but no success. It not a error for code as for as I am sure because I even tried opening working projects but same error. It may be problem with memory allocation but did't get solution. I am hoping any of you can help me that. Thanks a lot in advance. Your 10 min can save my 1 months work.

Regards,
Dr. Ashish Mishra
Sr. Engg.

[Repeater]

Your program is trying to read memory that doesn't belong to it. Probably through a bad pointer.

[AshishMishra]

Hey Thanks for quick response. Actually the same code was running one day before and I did saved it in .rar file. But now if extract and run the same thing it does shows this error. So I am not able to find which file got missed. Any Idea how to find it?

Bdw Thanks a ton.

[Repeater]

Sometimes bad code runs fine one day and crashes the next. Sometimes bad code will crash depending on what input you give it.

The error is not a missing file error. The error is reading memory that doesn't belong to you.

[AshishMishra]

Thanks, That clarifies a lot.
I suppose you are suggesting I should go back to Code and write it again. Because finding which memory it is not reading is difficult.

[jonnin]

yes, you need to debug it.
The error is operating system self defense. Operating systems allocate memory to one program, and any other program that tries to access it gets terminated as it 'looks like virus or bad behavior'. Rather than let one program corrupt (intentionally or not) another program and crash it too, it kills the one trying to reach outside its sandbox. That keeps the real owner of the memory safe.

a quick example of how to make this happen:
int *goof; //this randomly points to somewhere in ram, it could be anywhere and belong to any other program or none. But it COULD randomly also belong to YOUR program and be 'legal' (from the OS perspective).
goof[100000] = 11; //modify the memory that did not belong to you (most likely, it could have, of course). This will usually crash.

the most common causes of it are uninitialized pointers, dead pointers (deleted), carelessly running off the end of a container (array, vector, string, and possible others), and so on.

[Repeater]

I suppose you are suggesting I should go back to Code and write it again. Because finding which memory it is not reading is difficult.

Running under a debugger will tell you the exact line of code causing the crash.

[AshishMishra]

Hi Jonnin,

Based on my research it seems you catch the exact thing I am talking about. It must be the reason because I am 100 % sure the code is fine. Thought I did deleted few pointers which are not in use. That might have triggered it.

The real question is what now? Do have any Idea how to resolve it. Another problem now is that it has saved same changes in all the projects previously created in same folder and ever one of them shows same error.

Do you think it possible to resolve it some how? Rather coding everything from scratch and if later comes same issue again then keep repeating until I am lucky enough to get lucky code. i wanted to find the solutions.

Thanks for response.
Ashish

[Repeater]

Do have any Idea how to resolve it.

Don't do manual memory management. No new. No delete. No malloc. No free.

No arrays.

[jonnin]

no one can tell you how hard it will be to fix with no source code posted, but these tend to be challenging to run down. You may get lucky and run it in debug mode and find it right away, or it could take months, or even be impossible to find. You can try a binary search if the code is not multi-threaded, put print statements "I am here" in the code to see where it was when it died. If you wrap that up you can disable it with a compiler flag, for your release version.

Your code is NOT fine. No matter how much you think it is, it would not crash if it were fine. You can try the previous version to see if you broke something recently, sure. But the current version is broken.

Ideally, you would avoid these problems as Repeater said. If you have too much code to do that now, learn from it and do it better next time, and you are going to have to debug it and find and fix the issue in the current code.

one last thing... a month of work can often be reproduced in a week or less. The hard part, the design, the logic, all the stuff you figured out and debugged, its fresh in your head and you know what you did. And some of the code can be saved ... parts that don't do any pointer/memory work are probably OK. And you can do it better the second time around. If you choose to rewrite it, it should be much, much faster and easier the second time around.

[helios]

coding everything from scratch and if later comes same issue again then keep repeating until I am lucky enough to get lucky code.

No one is saying you need to write everything all over again. You just need to find whatever is broken in your code and fix it.
Thinking of it as "getting lucky" is weird, and I've certainly never heard myself or any of my colleagues speak of their work like this. Are your actions causally disconnected from the code you write? Do you hit keys at random until a working program emerges like the proverbial infinite monkeys? That would certainly take a lot of time.

[AshishMishra]

Thanks Jonnin and Helios for your responses.
@Helios: Actually you gave answer I was looking form though in a different way. anyways "You just need to find whatever is broken in your code and fix it." . Thanks man.