Advertisement

allocating memory!!

Started by September 27, 2000 04:24 PM
13 comments, last by WymsicalWyvern 24 years, 3 months ago
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
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.
Advertisement
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:

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?
But then again, there are a lot more ways of corrupting your memory.
How about writing beyond dynamically allocated array boundaries? They corrupt your heap.

Goodluck anyway,

Jaap Suter
____________________________Mmmm, I''ll have to think of one.

This topic is closed to new replies.

Advertisement