HeapAlloc & writing to memory

[Pentacle]

I'm trying to make a small proc that will fill a memory space with RGBA values later used for textures, but now matter how I access the memory or rewrite the dereference field, the program exits/crashes spontaneously when reaching the code.

Code Select Expand

invoke HeapCreate, HEAP_GENERATE_EXCEPTIONS, 0, 0   ;;make heap
     mov heapHandle, eax                 ;;save handle, check success
     .IF (!eax)
           ret
     .ENDIF
     
     invoke HeapAlloc, heapHandle, HEAP_GENERATE_EXCEPTIONS or HEAP_ZERO_MEMORY, 12288    ;;allocate memory, zero just in case.
     mov heapPointer, eax                ;;save pointer, check success
      .IF (!eax)
        xor eax, eax
        ret
      .ENDIF
     
      invoke RawI_RGBAFill, heapPointer, 12288, 4294967295 ;; 64x48x4 size, 0xFFFFFFFF color

Code Select Expand

RawI_RGBAFill proc buffer:DWORD, buf_size:DWORD, color:DWORD

shr buf_size, 2
mov eax, buf_size                       ;;measure DWORD loop count
xor ecx, ecx                            ;;clear counter


.while eax > ecx
push color                 ;;push & pop color from memory
pop DWORD PTR [buffer + ecx*4]
inc ecx                   ;;inc counter
.endw

mov eax, 1
ret

RawI_RGBAFill endp

I've tried using indirect addressing in various, some elaborated, ways and still no go.  A weird oddity is that if I replaced 'buffer' with a register (placing 'mov edx, buffer' before .while) the code does absolutely nothing.

I'm stumped, any ideas?

[asmfan]

Tatally suboptimal.
1. Load all values in registers (buff addr, size, ARGB...)
2. Use the simpliest way - rep stosd... Or write your analog.

[drizz]

A weird oddity is that if I replaced 'buffer' with a register (placing 'mov edx, buffer' before .while) the code does absolutely nothing.

thats not true, if you place "mov edx,buffer" before .while the code is error free

[Pentacle]

Tatally suboptimal.
1. Load all values in registers (buff addr, size, ARGB...)
2. Use the simpliest way - rep stosd... Or write your analog.

I used the registers, the stack, memory calls, it just doesn't seem to work no matter my methods.  Perhaps there is some sort of access violation but doesn't want to give me an error.

thats not true, if you place "mov edx,buffer" before .while the code is error free

Yes, the code looks error free, and makes sense.  After compiling and running it, the memory wasn't written to and I can't figure out why.

[Ossa]

Your problem is this definately this line:

Code Select Expand

pop DWORD PTR [buffer + ecx*4]

"buffer" is a parameter on the stack, so cannot be used in this way. Try this (should be faster too):

Code Select Expand

RawI_RGBAFill proc buffer:DWORD, buf_size:DWORD, color:DWORD

mov ecx, buf_size
shr ecx, 2
mov eax, color
mov edx, buffer
@@:
mov [edx], eax
add edx, 4
sub ecx, 1
jnz @B

mov eax, 1
ret

RawI_RGBAFill endp

sorry, I just formatted my computer today, so I don't have MASM installed just at the moment to check if that works.

Ossa

[tenkey]

Code Select Expand

pop DWORD PTR [buffer + ecx*4]

Definitely a problem, this will attempt to store a value into an "array" in the parameter list. Of course, you don't have an array in the parameter list.

All of the variable parts of an address (a pointer is a variable value) must be in registers for addressing.

Code Select Expand

mov eax,buffer              ; load pointer parameter into register
pop DWORD PTR [eax + ecx*4] ; now, we can store the value


[drizz]

Yes, the code looks error free, and makes sense.  After compiling and running it, the memory wasn't written to and I can't figure out why.

if you did this:

Code Select Expand


mov edx,buffer
.while eax > ecx
push color                 ;;push & pop color from memory
pop DWORD PTR [edx + ecx*4]
inc ecx                   ;;inc counter
.endwthe code has no errors and your bug is somewhere else (memory is color filled guaranteed)

[Ossa]

Why push and pop? why use inc? much better to use just the standard regs with movs.

Ossa

[drizz]

Why push and pop? why use inc? much better to use just the standard regs with movs.

both me and tenkey had no intention to optimize his code, that's irrelevant... :wink