Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is...
Pages: 12
Hi
It's not ideal to have more than one topic about the same problem. We don't want to play tennis, bouncing from one to the other. I suggest quitting one topic and keep the other one going. Put a post in both topics to that effect.
It is still not clear whether this is actual C++ code or a variation of it like C++/cli.
I wrote about that in the other topic ...
How much is is tons and tons? Try to post it somewhere - github maybe? Then we can criticise the design and the code, identifying other problems, not just what you think are problems. We can also compile it on our systems.
So a classic Stack Overflow, as said before, best fixed by using STL containers such as
Another thing: As said before, It's almost certain that you are not the first person to do this problem; this is an anti-pattern named Invented HereTM . So search for library code where someone has done it properly and try to learn from it.
It's not ideal to have more than one topic about the same problem. We don't want to play tennis, bouncing from one to the other. I suggest quitting one topic and keep the other one going. Put a post in both topics to that effect.
It is still not clear whether this is actual C++ code or a variation of it like C++/cli.
| Could it be because my code is bloated? I have tons and tons of code in the main function of the program.. |
I wrote about that in the other topic ...
How much is is tons and tons? Try to post it somewhere - github maybe? Then we can criticise the design and the code, identifying other problems, not just what you think are problems. We can also compile it on our systems.
So a classic Stack Overflow, as said before, best fixed by using STL containers such as
std::vector, std::array etc, which do a very good job of their own memory management, so you or anyone else don't have to worry about it.Another thing: As said before, It's almost certain that you are not the first person to do this problem; this is an anti-pattern named Invented HereTM . So search for library code where someone has done it properly and try to learn from it.
Re C6262. Your main local variables are using so much memory that they have exceeded the stack size (large arrays??). Function local variables are stored on the stack which has a fixed maximum size. Try making some of the ones using the most memory static which moves them off the stack.
you can kick the can down the road on most compilers by playing in the settings/flags area and increasing stack size. This only gets you so far, but if you are just touching the edge of your limit and don't need to keep getting bigger after that, it may solve it as-is.
Manually increasing the stack size from its default is putting lipstick onto a pig, it is covering up what likely is a less than good design choice.
Same with manual memory management when there are standard library alternatives available.
It is a hell of a way to learn what not to do for future projects.
Same with manual memory management when there are standard library alternatives available.
It is a hell of a way to learn what not to do for future projects.
The option is there to be used for when it makes sense to do so.
The issue is simply that, as I said, it kicks the can down the road.. if you keep doing what you have been doing and eating up your stack, its what George said and of little value, or worse, negative value since you are piling bad on top of bad.
An example of when to do it would be if you have a few large, static lookup tables that need just a little bit more than the default provides, then up to the next notch and its done and works forever, its fine. No problems. Its generally a bad idea to eat so much stack (again, echoing George) but now that you did, you can choose to hunt down some of the offending memory hogs and move them to the heap or you can play with the limit. Choices are good things.
The only issue I can remotely think of that you may see if using this option correctly would be that not every system and compiler and os etc have the same stack limit options. You can't increase the stack past what the hardware and OS support, and you can't set an option that isn't available, so if you plan to port the code, its a serious consideration to use the flag at all. If you are trying to write portable code, burning up your stack is an extra bad plan, esp if some of the targets are smaller, embedded etc type systems. There may also be a performance hit, but this seems like a concern from 40 years ago, not modern systems.
TLDR: It won't break your program, but you may not be able to compile a working program on every system in the world.
The issue is simply that, as I said, it kicks the can down the road.. if you keep doing what you have been doing and eating up your stack, its what George said and of little value, or worse, negative value since you are piling bad on top of bad.
An example of when to do it would be if you have a few large, static lookup tables that need just a little bit more than the default provides, then up to the next notch and its done and works forever, its fine. No problems. Its generally a bad idea to eat so much stack (again, echoing George) but now that you did, you can choose to hunt down some of the offending memory hogs and move them to the heap or you can play with the limit. Choices are good things.
The only issue I can remotely think of that you may see if using this option correctly would be that not every system and compiler and os etc have the same stack limit options. You can't increase the stack past what the hardware and OS support, and you can't set an option that isn't available, so if you plan to port the code, its a serious consideration to use the flag at all. If you are trying to write portable code, burning up your stack is an extra bad plan, esp if some of the targets are smaller, embedded etc type systems. There may also be a performance hit, but this seems like a concern from 40 years ago, not modern systems.
TLDR: It won't break your program, but you may not be able to compile a working program on every system in the world.
Last edited on
| you can choose to hunt down some of the offending memory hogs and move them to the heap or you can play with the limit |
Or make them static or file scope which moves them off the stack.
Topic archived. No new replies allowed.
Pages: 12