strange behavior of local variables

[ossama]

hello,
when i was writing a procedure, i needed local variables,but the problem is when the total size of these local variables is more than 16312 bytes (this value may change in your system) the procedure is not called.
to explain this i have written a demo:

Code Select Expand


.586
.model flat,stdcall
option casemap:none

include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc

includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib

BUFFER_SIZE EQU 16313

.code
start:
call my_proc
invoke ExitProcess,0

my_proc proc
local buffer[BUFFER_SIZE]:byte

invoke MessageBox,0,0,0,MB_OK
ret
my_proc endp

end start


what is going on ?

[Vortex]

ossama,

On my system ( Win XP Pro Sp2 ), I get a buffer of 16316 bytes. The stack is aligned to the nearest DWORD boundry, this is why the total size of your local variables is not 16313 bytes.

[ossama]

hi vortex,
but what can i do?

[Vortex]

ossama,

Why not to use memory allocation functions? They are more flexible as you have the opportunity to resize the allocated memory portion.

[ossama]

yes , i was thinking about using memory allocation functions , but i was asking here if there is another issue before i use memory functions.

[donkey]

Hi ossama,

For large blocks of memory you should be using the memory allocation functions as Vortex has said, there are no particular issues when using them except that you might have to address them a bit differently than you would with stack based memory. Beyond that little difference memory allocation offers many advantages and you'll never have to worry about stack sizes. For 16KB you can use the heap functions...

HeapAlloc
HeapFree
HeapReAlloc
HeapSize

Or for larger allocations (>4MB) use the Virtual memory functions...

VirtualAllocEx
VirtualFree
VirtualLock
VirtualProtect
VirtualQuery

Donkey

[ossama]

so the memory allocation is the issue,ok , thank you for help  :U

[raymond]

Or for larger allocations (>4MB) use the Virtual memory functions...

I have allocated as much as 100Mb without any problem using GlobalAlloc. I don't know about HeapAlloc or LocalAlloc, but I would assume they could also be used for allocating more than 4Mb.

[ossama]

i am using CoTaskMemAlloc and CoTaskMemFree all the time,i did not used them in large memory allocations.

[Mirno]

Raymond, GlobalAlloc & LocalAlloc are depreciated, and map on to VirtualAlloc for compatability. So while you can use them, it's best not to if possible (new projects & rewrites).

As for the problem at hand, can you try adding:

Code Select Expand


mov buffer[4095], 0
mov buffer[8191], 0
mov buffer[12287], 0

Between the declaration, and the invoke of messagebox?

I suspect it may be a pagefault issue.

Mirno

[ossama]

I suspect it may be a pagefault issue

is the orgine of fault from the assembler or the OS?

[Mirno]

When Windows allocates stack space, it does so by monitoring page faults (when you access an address that hasn't been assigned physical memory yet), and if it's adjacent to the current top of the stack then it adds more to the stack.
If you try to touch an address that's more than a single page from the stack then it acts like a "normal" page-fault and errors.

By adding the movs you force windows to allocate it, before moving on to the next page.

[ossama]

Raymond, GlobalAlloc & LocalAlloc are depreciated, and map on to VirtualAlloc for compatability. So while you can use them, it's best not to if possible (new projects & rewrites).

As for the problem at hand, can you try adding:

Code Select Expand


mov buffer[4095], 0
mov buffer[8191], 0
mov buffer[12287], 0

Between the declaration, and the invoke of messagebox?

I suspect it may be a pagefault issue.

Mirno

i did the above movs between declaration and the invoke,but the same problem.

[ToutEnMasm]

Hello,
For the stack,you must use "VirtualQuery" and other API in Virtual....
I join a sample that allocate,unallocate the memory stack with these functions.
Unhappy,comment are in french,just ask i will reply.


[attachment deleted by admin]