When we free a memory area...

Dräc · Post by **Dräc** » Sat May 14, 2005 8:27 am

Why, when we free a memory area, we notice that the values of the first two bytes change?
I expected that FreeMemory() indicates simply to the processor that the area is again available to be reused in whole or in part by another process, but without that a value of this area was changed!

For me, changes it’s not to mean that the memory is empty, because I imagine that the memory supervision is the task of a memory manager. It belongs to it to know the free and busy memory parts, to allocate some memory, etc....
It is much simple for the microprocessor!

Thus Why? What is the interest?

Silly idea: is it a safety measure coupled to linkedlist?

Code: Select all

Structure elmt 
  a.l 
  b.l 
  c.l 
  d.l 
EndStructure 

*List.elmt = AllocateMemory(SizeOf(elmt)) 
*List\a = 10 
*List\b = 11 
*List\c = 12 
*List\d = 13 

Debug *List\a 
Debug *List\b 
Debug *List\c 
Debug *List\d 

Debug "---------" 
FreeMemory(*List) 

Debug *List\a 
Debug *List\b 
Debug *List\c 
Debug *List\d

Psychophanta · Post by **Psychophanta** » Sat May 14, 2005 9:13 am

Hi
When a memory zone is freed, the contents into it are unpredictable. It is intended that after the mem is freed we will no access to its contents.

Dräc · Post by **Dräc** » Sat May 14, 2005 9:24 am

I agree with you on the fact that once the memory freed, its contents are not any more guaranteed. But I notice that it is systematic that the first two bytes are modified.
This way, I have the feeling that it is FreeMemory() which change them and not another process.
Perharps it’s wrong!
But I shall like knowing if it is FreeMemory() itself which produces this modification of the first two bytes or not?
If true, why?

Psychophanta · Post by **Psychophanta** » Sat May 14, 2005 9:28 am

Mmmh, dunno. Maybe FreeMemory() performs same task that MS API.
Have you tested to allocate and free memory using the api function instead?

Post by **Fred** » Sat May 14, 2005 12:29 pm

FreeMemory() is just a wrapper for HeapFree()

Dräc · Post by **Dräc** » Sat May 14, 2005 12:52 pm

Ok, nothing to see with a PureBasic interest.
But are you all right to say that apparently freeing a memory zone does not inevitably ask to change byte of it?!

PS: if it is the case, I do not go to know more about it, it is just for clarified me the theoretical memory deallocation act.

Kale · Post by **Kale** » Sat May 14, 2005 2:43 pm

I guess I could argue that if your freeing the mem area, why do you care about that address anymore!

Post by **Fred** » Sat May 14, 2005 4:31 pm

It probably depends of the underlying implementation. Does it do the same with the API ?

Dräc · Post by **Dräc** » Sun May 15, 2005 2:28 pm

Yes, the same!

Code: Select all

Structure elmt 
  a.l 
  b.l 
  c.l 
  d.l 
EndStructure 

heap = HeapCreate_(0, SizeOf(elmt), SizeOf(elmt))
*List.elmt = HeapAlloc_(heap, 0, SizeOf(elmt))
*List\a = 10 
*List\b = 11 
*List\c = 12 
*List\d = 13 

Debug *List\a 
Debug *List\b 
Debug *List\c 
Debug *List\d 

Debug "---------" 
HeapFree_(heap, 0, *List)

Debug *List\a 
Debug *List\b 
Debug *List\c 
Debug *List\d

Xombie · Post by **Xombie** » Sun May 15, 2005 8:19 pm

For some reason I thought AllocateMemory() and FreeMemory() were wrapping LocalAlloc_() and LocalFree_() for Windows. What's the difference between HeapAlloc_() and LocalAlloc_()? And as a side question, is there a large programmatic difference between using #GMEM_MOVEABLE or #GMEM_FIXED for LocalAlloc_() ? ie, would it cause a problem program-wise if either were used? In addition to #GMEM_INITZERO to initialize the contents to zero.

Post by **freak** » Sun May 15, 2005 9:23 pm

The Local memory functions are the old Api coming from the days of 16 bit Windows.
They are only still present in 32bit windows versions to maintain backwards compatibility.
They are slower and provide less functionality than the Heap Functions.

You really shouldn't use them.

Xombie · Post by **Xombie** » Mon May 16, 2005 12:09 am

hmmm... so for every time we want to use the api to allocate memory would we call a HeapCreate_() followed by a HeapAlloc_() or would we call HeapCreate_() once with a large initial size and then HeapAlloc_() just what we needed?

(and sorry for hijaaking your thread >_< This stuff just came up for me in the program I'm writing so it's important for me to find out ^_^;; )

For instance, do we do...

Code: Select all

idHeap = HeapCreate_(0, 100, 100)
*OnePointer = HeapAlloc_(idHeap, #HEAP_ZERO_MEMORY, 10)
*TwoPointer = HeapAlloc_(idHeap, #HEAP_ZERO_MEMORY, 10)
*ThreePointer = HeapAlloc_(idHeap, #HEAP_ZERO_MEMORY, 80)
HeapFree_(idHeap, 0, *OnePointer)
HeapFree_(idHeap, 0, *TwoPointer)
HeapFree_(idHeap, 0, *ThreePointer)
HeapDestroy_(idHeap)

or do we do...

Code: Select all

idHeap01 = HeapCreate_(0, 100, 100)
idHeap02 = HeapCreate_(0, 50, 50)
*OnePointer = HeapAlloc_(idHeap01, #HEAP_ZERO_MEMORY, 100)
*TwoPointer = HeapAlloc_(idHeap02, #HEAP_ZERO_MEMORY, 50)
HeapFree_(idHead01, 0, *OnePointer)
HeapFree_(idHead02, 0, *TwoPointer)
HeapDestroy_(idHeap01)
HeapDestroy_(idHeap02)

?

Which method is the correct way to do it?

<Edit>

Aha! Scratch that. I'm guessing that it's the first way and that that is how PB does it since it's wrapping the Heap functions. I guess it does a HeapCreate_() at the start and then all AllocateMemory() calls just use that one heap, yeah? Probably with a 0 maximum size on the HeapCreate_() so that it can grow? Ahah....

Post by **Fred** » Mon May 16, 2005 12:41 am

Only create one heap and then call HeapAlloc() for subsequent allocations.