Problems w/ GlobalFree 1

[KSW2]

Using GlobalAlloc to create space for large vectors whose size needs to be defined and often changed during runtime. I thought I was being careful by using GlobalFree to free the space when no longer needed and before new vector sizes are allocated. When I do this, however, I get random (but guaranteed to happen eventually after a few changes in allocation) crashes often w/o error messages in Visual C++. The strange thing is that if I never free the space no crashes occur and I don't seam to be losing memory either. Any ideas on what's going on?

 

[Zyrenthian]

Well, I assume that you use GlobalRealloc when the program starts to adjust the size. Do you use GlobalLock? Another approach is VirtualAlloc and VirtualFree and we have used that in the past. We dont any more because we "thought" there may be a leak within it. It is my opinion, however, that there are not any.

Matt

 

[KSW2]

Maybe that's the problem. I use GlobalAlloc when I know the size of the array, solve the problem, then use GlobalFree to free the memory. When I get a new vector size I again use GlobalAlloc thinking that I freed it previously and, therefore, should use GlbalAlloc as if creating a new vector (using the same pointer name though). Am I incorrect in thinking that way? Even though I freed the memory for that vector is GlobaReAlloc the right thing to use?

I used to use the GLobalLock (had similar problems) but think I read you don't need it anymore with Win32.

Thanks for the feedback.

 

[Zyrenthian]

You can verify that the global free worked properly...

if(GlobalFree(hMem))
{
TRACE("GLOBAL FREE FAILED\n"
// call get last error

}

Matt

 

[Zyrenthian]

I just had a thought. When I was dealing with our memory issues here, what the real problem was, was not with a VirtualFree but with the VirtualAlloc. Because so many large segments of memory were being used and then small portions were scattered here and there, even though GetSystemInfo "SAID" i had enough memory, it could not tell me if that memory was in one large congiguous block. The memory was becoming fragmented. Our approach was to use SetProcessWorkingSetSize to 75% of the available memory. I STRONGLY suggest not going above 75%. For the min we used 35% of the available memory. Yes this helped but it only prolonged our crash. I then developed a way to allocate the large block of memory and manage it myself. A call to free didnt really "free" the memory but just held onto it and gave it back when it was needed. The destructor handled the destruciton of allocated memory. It was a bit of work but once again, it prolonged the life of the app. Now we went to 3rd party software which manages the memory for us and all is well. It was actually the reason why we found that DC problem I posted. Basically, dont free the memory until the end of the app and see what happens. Just zero it out and continue on your merry lil' way

Matt

 

[KSW2]

Thanks, that seems to work. I've been checking memory and don't seem to be losing any with that approach- just don't know why or don't understand what Microsoft is doing.

 

[Zyrenthian]

I DONT THINK MICROSOFT KNOWS WHAT THEY ARE DOING

Matt

 

[tchouch]

This error may be too, if You write or read more bytes, as Your array has. It can be an another array (in another function too), that You use before You frees the memory! To find it out, You should look in debugger, on witch address the Error is, and find the array or somewhat like it, which addresses it may be.