Globalfree problem

[ecube]

I can't seem to get globalfree to work, in the example below I run the program, you see it's starting memory, it allocs memory then doesn't free it, any help would be much appreciated, thanks.

Code Select Expand


.586
.model flat, stdcall
option casemap:none

include \masm32\include\windows.inc

include \masm32\include\advapi32.inc
includelib \masm32\lib\advapi32.lib

include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib

include \masm32\include\user32.inc
includelib \masm32\lib\user32.lib

include \masm32\include\masm32.inc
includelib \masm32\lib\masm32.lib


.data?
cpubuffx_M dd ?
cpubuffx dd ?

.code
start:
invoke Sleep,10000
invoke  GlobalAlloc, GHND,30000
mov cpubuffx_M,eax
invoke GlobalLock, cpubuffx_M
mov cpubuffx, eax
invoke Sleep,10000

invoke GlobalUnlock,cpubuffx
invoke GlobalFree,cpubuffx_M
invoke Sleep,10000
invoke ExitProcess,0
end start


[zooba]

How do you know it hasn't freed it?

For compatibility reasons, the memory may not be cleared when you free it, and there's a lot of performance metrics that don't accurately reflect the amount of allocated memory. In any case, you're better off using HeapAlloc/HeapFree, as Global* and Local* memory functions are deprecated.

Cheers,

Zooba :U

[ecube]

oh ok thanks for responding, I was checking taskmgr, seen the memory rise but not decrease...i'm using globalloc in threads so everytime that thread is created memory is increased but not decreased, making me uncomfortable

[gabor]

Hi!

Since you are allocating 30.000 bytes only it is quite difficult to check especially via the taskManager the amount of free RAM before and after.
There are many system and user processes that allocate and free up memory all the time.
Once,I too wanted to check for memory leaks and I noticed that the taskManagersimply does not work for this task.
I'm quite certain that there are no problems with your code, but to be sure try to allocate more memory (a few MB or more) either by increasing the amount or by creating the thread many-many times. This second way might be a bit problematic since threads are system resources registered and administered by the OS and creating hundreds of threads might cause troubles. However, I have to admit this is just a guess...

Greets, Gábor

[hutch--]

Unless you are doing DDE or clipboard requirements, the only form of GlobalAlloc() that is not out of date is the GMEM_FIXED flag version that returns a direct pointer. The other styles are mainly for 16 bit Windows name capacity.

[MichaelW]

And you can generally deterimine if a function failed by checking the return value.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    .data
      hMem dd 0
      pMem dd 0
    .code
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    print "rv GlobalAlloc (zero=error) "
    invoke GlobalAlloc, GHND, 100000
    mov hMem, eax
    print hex$(eax),13,10
    print "rv GlobalLock (zero=error) "
    invoke GlobalLock, hMem
    mov pMem, eax
    print hex$(eax),13,10
    print "rv GlobalUnlock (zero=unlocked or error) "
    invoke GlobalUnlock, hMem
    print hex$(eax),13,10
    print "rv GetLastError (zero=unlocked) "
    invoke GetLastError
    print hex$(eax),13,10
    print "rv GlobalFree (zero=success) "
    invoke GlobalFree, hMem
    print hex$(eax),13,10

    inkey "Press any key to exit..."
    exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start


Code Select Expand


rv GlobalAlloc (zero=error) 00310004
rv GlobalLock (zero=error) 00133268
rv GlobalUnlock (zero=unlocked or error) 00000000
rv GetLastError (zero=unlocked) 00000000
rv GlobalFree (zero=success) 00000000


[ecube]

Unless you are doing DDE or clipboard requirements, the only form of GlobalAlloc() that is not out of date is the GMEM_FIXED flag version that returns a direct pointer. The other styles are mainly for 16 bit Windows name capacity.

I know you don't like f0dder very muc Hutch  but he claims on his website heapalloc isn't faster than globalloc it's just like you said more appreciated now. So is there any reason why I shouldn't use Globalloc besides it's depreciated? Also thanks for the response guys and, MichaelW the code.

[hutch--]

Cube,

One of our members did a lot of testing some years ago on the allocation/deallocation speed of different memory strategies and the only slow one was OLE string memory but that was due to it doing more work and not fragmenting lke the majority of te other strategies. HeapAlloc() is faster on many small allocations but on larger single allocations GlobalAlloc() with the GMEM_FIXED flag is in fact very fast.

It was not designed for some of the later uses where code is managed in the background with automatic allocation and deallocation techniques so you would not use it for this task but that is hardly a problem with manually allocated memory. Now apart from DDE and the clipboard, the GMEM_MOVABLE style of allocations are simply out of date, they reflect the architecture of 16 bit Windows before multitasking went into hardware in 32 bit Windows.