Page 1 of 1
When we free a memory area...
Posted: Sat May 14, 2005 8:27 am
by Dräc
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
Posted: Sat May 14, 2005 9:13 am
by Psychophanta
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.
Posted: Sat May 14, 2005 9:24 am
by Dräc
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?
Posted: Sat May 14, 2005 9:28 am
by Psychophanta
Mmmh, dunno. Maybe FreeMemory() performs same task that MS API.
Have you tested to allocate and free memory using the api function instead?
Posted: Sat May 14, 2005 12:29 pm
by Fred
FreeMemory() is just a wrapper for HeapFree()
Posted: Sat May 14, 2005 12:52 pm
by Dräc
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.
Posted: Sat May 14, 2005 2:43 pm
by Kale
I guess I could argue that if your freeing the mem area, why do you care about that address anymore!
Posted: Sat May 14, 2005 4:31 pm
by Fred
It probably depends of the underlying implementation. Does it do the same with the API ?
Posted: Sun May 15, 2005 2:28 pm
by Dräc
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
Posted: Sun May 15, 2005 8:19 pm
by Xombie
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.
Posted: Sun May 15, 2005 9:23 pm
by freak
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.
Posted: Mon May 16, 2005 12:09 am
by Xombie
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....
Posted: Mon May 16, 2005 12:41 am
by Fred
Only create one heap and then call HeapAlloc() for subsequent allocations.