Problem with globalfree on Win7

[Farabi]

Im making an simple accounting system for my lecture, my software always crashed each time I free the memory using GlobalFree, did anyone experienced the same thing?

[KeepingRealBusy]

How did you allocate the memory?

[Farabi]

How did you allocate the memory?

Code Select Expand


invoke GlobalAlloc,GMEM_ZEROINIT or GMEM_FIXED,nSize
.if eax==0
invoke PERR
invoke MessageBox,NULL,addr mem_error,NULL,MB_OK
.endif


I dont know if it was just me or anyone else experienced the same thing.

[oex]

You are allocating alright I think but are you sure you are freeing the right pointer address on end?

invoke GlobalFree, MemoryAddress

Also *some* windows functions manage their own functionality or have their own memory free functions you should check windows API notes to be on the safe side

[hoverlees]

I think you may pass a wrong handle to the GlobalFree function.

[Farabi]

I think you may pass a wrong handle to the GlobalFree function.

Maybe, I used to allocate the memory and add it with 4.
for example

Code Select Expand


invoke malloc,128
add eax,4
invoke globalfree,eax


Is that now not allowed on Win7?

[Slugsnack]

No you should not change the pointer. The pointer effectively points to an object. By adding 4, you are now pointing to something else completely.

[oex]

Do this....

mov eax, alloc(128)
mov ebx, 100
mov [eax], ebx
mov [eax+4], ebx
etc
free eax

Note: eax has not changed.... if you try and free eax and you have changed it *your application will error
*Almost always

Also you could do this:

LOCAL Mem:DWORD

mov Mem, alloc(128) <---- Mem is Pointer to 128 byte buffer ie like LOCAL buff[128]:BYTE.... Mem = PTR buff (except created dynamically)
mov eax, Mem
mov ebx, 100
mov [eax], ebx
mov [eax+4], ebx
etc
free Mem

[sinsi]

Is that now not allowed on Win7?

I'm sure it's never been allowed in any windows.

hMem A handle to the global memory object. This handle is returned by either the GlobalAlloc or GlobalReAlloc function.

You can't give it a bogus handle, but maybe win7 is stricter?

[MichaelW]

Passing the pointer returned by malloc to GlobalFree seems strange, but it appears to work OK on my system, and the same with GlobalReAlloc.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    .data
    .code
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    invoke crt_malloc, 1000
    mov ebx, eax
    print hex$(eax),13,10

    invoke GlobalReAlloc, ebx, 1000, 0
    print hex$(eax),13,10               ; returns handle on success

    invoke GlobalFree, ebx
    print hex$(eax),13,10,13,10         ; returns null on success


    invoke crt_malloc, 1000
    mov ebx, eax
    print hex$(eax),13,10

    add ebx, 4
    invoke GlobalFree, ebx
    print hex$(eax),13,10               ; returns handle on fail

    print LastError$(),13,10,13,10

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


Note in the results that the ebx+4 value causes GlobalFree to return a different handle.

Code Select Expand


00792428
00792428
00000000

007939E0
007939E4
The handle is invalid.