heap versus globalalloc functions

phenix · 16 Jul 2014

Running windows 7 64-bit.
In the past I was running a 32-bit puter and seemed to use the
globalalloc functions without to many problems.
This particular program is giving me fits in converting it from
32-bit to 64-bit.
Questions: are the Globalalloc functions the cause of my problem
in a 64-bit puter? Getting consistent errors: C00005 and C000374.
The Microsoft site and the related messages there confuse the hell
out of me.
Is there a tutorial on this subject somewhere to help me get started
on the heap functions???? Guess I should be using them on the
Windows 7 64-bit puter.
Please give me some guidance.

MilesAhead · 16 Jul 2014

What programming language are you using? Does the code use any "wrap around" tricks where it assumes incrementing a pointer past the max integer value will "wrap around" to the start of the memory block?

0xC0000374 is supposedly heap corruption. It could be the sizes for allocated blocks are being overwritten perhaps because 64 bit integers are twice the size(or more likely the extra 32 bits of the integer are "bleeding over" into the data itself. Typically heaps have a size followed by the data follows by more of the same. Easy to corrupt it unless you specify the integer size when writing in the size info(meaning using a data type the same size as the structure expects.)

phenix · 16 Jul 2014

Thank you for responding.
I am trying to convert a MASM32 program to GoAsm 64-bit program.
I have not used any wrap around code in the program.
However I am using the old memory managment apis (globalalloc etc.)
To me the heap macros are a nightmare.

MilesAhead · 16 Jul 2014

It's been some time since I dabbled in assembler. But scanning the GoAsm 64 docs I notice that it does not reverse some immediate values(I assume when loading in a register) as masm does. I wonder if that could be where some confusion comes in. I think with global allocations there's a difference in minimum sizes allocated and that type of thing. In 32 bit I think physically a 4k page is allocated. But supposedly in x64 the sizes are much larger.

I haven't done much in the way of x64 programming. And that in VC++. The only suggestion I can think of is that perhaps the larger block sizes on x64 could create some overlap. One would think the memory manager would prevent that though. I wish I could be more help/

Alejandro85 · 16 Jul 2014

In the past, I've used GlobalAlloc a lot for personal projects, and never got a problem with it. A few of those are still running in my computer under 64 bits, with minor or no modifications. Even though they're 32 bit programs runnin under WOW now instead of native x64 programs like your case, I don't think it will make a difference.
The global and even the local functions are still available, even though the heap is the preferred choice. MSDN just point out this:

The global functions have greater overhead and provide fewer features than other memory management functions. New applications should use the heap functions unless documentation states that a global function should be used

Which says that global is slower and with fewer features, but still functional.

My wild guess without seeing any code. Check out pointer and variables size in general. Remember that all pointers will now be 8 bytes instead of 4, as well as the return values of functions. This implies that you need to use the full rax register for checking the return instead of just eax. When allocating stack and heap space for them, remember to recalculate the space and offsets from pointers. Data sizes in structures may also vary. A single badly sized pointer might result in the cpu to point to a completely different place (chance of C0000005) or corrupting random memory of your own program, causing unexpected behavior.

Try debugging the code, see where it blows up, and verify the return value from functions. In case of errors, ask GetLastError for details.

phenix · 17 Jul 2014

7-17-2014
Thanks so much for responding.
GoAsm 64-bit code used here

linetot dq 0 ; defined as 8 bytes
linetot has to be defined this way because of usage in other
parts of the program.
Local scr:SCROLLINFO
Scrollinfo is defined as a structure in Windows
of which scr.nmax is part of.
So how would this code be defined since items in the
Scrollinfo structure are double words?????
mov rax,Q[linetot]
mov D[scr.nMax],eax ??

Is this an example of a POINTER?
prog1lnectr db ' ',0 ; defined as 5 bytes
xor rsi,rsi
.loop1
cmp rsi,5
jge >>.loop2
mov B[prog1lnectr+rsi],030h
inc rsi
jmp <.loop1
.loop2