Memory allocation problems

Could you explain what you mean by "no longer get past initialization"?

Could it be that there''s a bug in your bitmap surface allocation causing it to trash memory somewhere? What happens if you do your CNode allocation before this?

Mike.

You are right. If I allocate the map before I read in my pcx images everything works fine. I don''t see how they are trashing memory though. I have a standard pcx image type defined :

typedef struct pcx_picture_typ {
pcx_header header;
UCHAR *buffer;
} pcx_picture, *pcx_picture_ptr;

As I load in the picture I do this in a separate function which I call once during initilization for each image I want loaded(which is before my PeekMessage loop).

-Read in header

-Allocate buffer memory (8bit):
image->buffer = new UCHAR[(image->header.width+1)*(image->header.height+1)];

- Read in RLE data
- Read in palette if necessary
- Create a direct draw surface of the same size

Difficult to say where it could be without seeing the code. But I''d say it''s most likely that you''re writing past the end of the allocated memory during the run length decoding. Also are you allocating memory for the palette if there is one?

Mike.

Well, Mikey you were correct, the problem was in my decoding. This was the line that caused me all of this trouble:

while(count<=((image->header.width+1)*(image->header.height+1)))
.. rle and increase count as needed

That should have been a < and not a <= This was causing me to go one UCHAR past the end of my allocated buffer. I guess in most of the cases this memory was not important and I had no problems, but in the last one I added this was writing over something protected. :/

Aren''t those the most difficult bugs to track down - those pointer bugs where it will still work most of the time. Anyway, thanks for the help. Between you and the error log I created while looking for this bug I tracked it down. Hopefully this log will make my job easier in the future.

Abs

p.s. I have another memory allocation question. I read somewhere that if you don''t delete your dynamically allocated memory (i.e. using the new keyword) at the end of your program that the memory is lost until you restart your computer (atleast under Win98). I thought that once your program terminates this memory will be returned to the free heap? In either case I always match new with delete, but I was just wondering for educational purposes.

I don''t believe so. Each process has its own virtual address space. When your process terminates that address space goes away along with all memory allocated by the process.

The memory returns to the heap properly in WinNT but in Win9x it seems to have problems with it _sometimes_.

At least that''s what I''ve found.

Regards,
Nekosion

quote:

---

p.s. I have another memory allocation question. I read somewhere that if you don''t delete your dynamically allocated memory (i.e. using the new keyword) at the end of your program that the memory is lost until you restart your computer (atleast under Win98). I thought that once your program terminates this memory will be returned to the free heap? In either case I always match new with delete, but I was just wondering for educational purposes.

---

It''s true. To test it out, create a program that does something like X = new char[1000]; and don''t delete it at the end. Run this program several times over, and you''ll notice that your system resources go down, and down, and down...

Then I hear some people talking about how Windows has some protection against this kind of thing and unallocates any allocated memory at the end of the program, but that''s whack, or maybe only partly true.