hmmm... well i think i can safely conclude that its a not enough memory problem, i can allocate 50x50x2 bytes fine (in addition to 800x600x3, and a 50x50x2 ) but i can''t allocate 50x50x3, right? so i tried that /heap: thing but the docs says:
"Specify the reserve and commit values in decimal or C-language notation"
first of all what unit is it in? and what does it mean by c-language notation?
i tried everything in that parameters but nothing seemed to help. Any ideas?
The Wymsical Wyvern
allocating memory!!
you can try using "try and catch" to see error info.
To the vast majority of mankind, nothing is more agreeable than to escape the need for mental exertion... To most people, nothing is more troublesome than the effort of thinking.
Hi there,
I would like to place a bet on this. Your problem is a memory corruption some place earlier. For example consider this code:
The above example of deleting a pointer twice might seem obvious but it is often very hard to track cause the deletion might happen at different places, in different classes, in different methods, in different destructors etc.
Anyway, this is only one of the many ways that you can cause a heap (memory) corruption. The problem is this:
the corruption won''t be noticed until you start doing things later on about on the same place that the corruption occured. BOOM, acces violation.
You''re corruption is probably somewhere at the end of the part you wanted to allocate. That''s why no error occured when you allocated less, cause the corrupted memory wasn''t touched.
new does NOT give you errors even if you have not enough memory cause then it throws an exception (that doesn''t give you a acces violation even it isn''t handled). Anyway, long story, but no solution yet. HOLD ON! hehe.
The solution. USE THE DEBUG HEAP. ALWAYS!!!!!!!!!! Well, at least I''m talking about MSVC++ now here. Be sure to include "crtdebug.h" in all your files (indirectly or directly) and be sure to define _NDEBUG (which is probably already defined for debug builds).
This way the new and delete operators will use the debug heap in debug builds. And you will find your memory corruption at the time it happens and not some place later on.
In release builds your debug new and delete will compile into normal regular straight c++ new and delete so DON''T worry about speed issues here.
I have the debug heap on constantly cause even the best programmers (which I am not hehe) make memory corruptions in their code.
Goodluck and email me with your questions,
Jaap Suter
____________________________
Mmmm, I''ll have to think of one.
I would like to place a bet on this. Your problem is a memory corruption some place earlier. For example consider this code:
int* p = new int[ 300 ];delete p;// Lots of other code...delete p; //AGAIN??????
The above example of deleting a pointer twice might seem obvious but it is often very hard to track cause the deletion might happen at different places, in different classes, in different methods, in different destructors etc.
Anyway, this is only one of the many ways that you can cause a heap (memory) corruption. The problem is this:
the corruption won''t be noticed until you start doing things later on about on the same place that the corruption occured. BOOM, acces violation.
You''re corruption is probably somewhere at the end of the part you wanted to allocate. That''s why no error occured when you allocated less, cause the corrupted memory wasn''t touched.
new does NOT give you errors even if you have not enough memory cause then it throws an exception (that doesn''t give you a acces violation even it isn''t handled). Anyway, long story, but no solution yet. HOLD ON! hehe.
The solution. USE THE DEBUG HEAP. ALWAYS!!!!!!!!!! Well, at least I''m talking about MSVC++ now here. Be sure to include "crtdebug.h" in all your files (indirectly or directly) and be sure to define _NDEBUG (which is probably already defined for debug builds).
This way the new and delete operators will use the debug heap in debug builds. And you will find your memory corruption at the time it happens and not some place later on.
In release builds your debug new and delete will compile into normal regular straight c++ new and delete so DON''T worry about speed issues here.
I have the debug heap on constantly cause even the best programmers (which I am not hehe) make memory corruptions in their code.
Goodluck and email me with your questions,
Jaap Suter
____________________________
Mmmm, I''ll have to think of one.
____________________________Mmmm, I''ll have to think of one.
hmm.... well i tried including that, BUT, it can''t find it. and another thing, up to the point where its crashing, i haven''t deleted anything yet, is there any other way to corrupt the heap?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement