Alloc - program hangs

[DanWebb314]

Hello
   I am new to 'MASM' I have done some C++ and C# programming.  I have done some Assembly programming on other computers: Radio shack color computer and some computers used by the military while in the Navy.

Ok  here is my question.


The following code demonstrates a problem I am having with a larger program I have written to sieve prime numbers.  When I allocate a small amount of memory, the program works fine.  But when I allocate larger amount of memory the program hangs up.

Code: [Select]


    invoke Alloc, 1245200
    mov ebx, eax
    nop
    add ebx, 1245100
    mov  BYTE PTR[ebx], 0  ;  this instrustion executes ok.
    add ebx, 90
    mov  BYTE PTR[ebx], 0   ;  this instrustion fails in debug.

The debugger  hangs on the above instruction and shows this:

Code: [Select]

DS:[013E0026]=???

It acts link I am accessing memory it does not want my program to use.  But I am within the bounds of the memory ‘alloc’ gave me.  How do I fix this problem?

Thank you in advance
Dan

[qWord]

Did you check the return value of Alloc() for validity? Also, are you freeing up allocated resources if no longer needed?

[jj2007]

As an isolated mini-app it works fine. In your larger app, there may have been problems that corrupted the heap - see qWord's question. By the way, Alloc uses CoGetMalloc "under the hood" - perhaps you try with HeapAlloc?

[Ryan]

There's a bug?

http://www.movsd.com/board/index.php?topic=7004.0

[MichaelW]

I don't recall all the details, but I do recall that in the attached test the original Alloc procedure (the bugged one AFAIK, included with MASM32 v10) was the only one other than VirtualAlloc that provided a consistent alignment >= 16 bytes, so I think it would be worth fixing.

And I see that the MASM32 v11 procedure is the same, so AFAIK it's still the bugged one.

[hutch--]

If you want simple hassle free memory allocation, use the MASM32 macro "alloc" (note lower case, not the procedure version) which calls GlobalAlloc(). Free it when finished with the macro "free" or the API function GlobalFree().

[dedndave]

oh - i was going to suggest VirtualAlloc   :P
it seems he is trying to allocate more memory than is available

[DanWebb314]

I have tried to fix Alloc by adding:

Code: [Select]

push 0            ; <========================================


I have tried 'HeapAlloc' and 'alloc': Both get rejected when I compile.

I found that 'stralloc'  works fine.  Much better that 'Alloc'.  With 'stralloc' I have gotten 2^28 bytes of memory.  which is what I need for my sieve program to find all 32bit prime numbers.

[dedndave]

must be working on Euler
i need to do a few more to get my 25   

[KeepingRealBusy]

oh - i was going to suggest VirtualAlloc   :P
it seems he is trying to allocate more memory than is available

Dave,

It depends on what you mean by "available". You can allocate 3GB of Virtual memory on a system with only 2 GB of real memory if you have a paging file that can support 3 GB and you modify C:\BOOT.INI with the /3GB switch (watch out, boot.ini is usually System and Hidden and I believe you need to be an Administrator).

Dave.

[MichaelW]

That would be 3GB of S-L-O-W Virtual memory on a system with only 2 GB of real memory...

[KeepingRealBusy]

Michael,

It depends on how you are accessing it. If you look at how a quicksort works, not too many pages are accessed at any time (the pivot is always there and one page table word scans the memory from the front of the array and another scans from the back of the array and the possible exchange just uses the second and third page table word). As the sort progresses, the adjacent values are grouped, the lower values together and the higher values together. Then the smaller front and back halves are themselves sorted the same way. If you had a linked list and tried to sort, each access would potentially access another page thus causing heavy paging. The same thing would happen if you had an array of pointers to strings that was being sorted (just swapping the pointers to logically pit the entries adjacent to each other). The code for procedures is mostly contained on one page so loops do not really cause heavy paging, even if you are in a loop calling some other procedure, you would only use 2 pages.

So, paging depends a lot on how you are using the memory.

Dave.

[dedndave]

sounds like a good place to write a new set of functions   :P

function 1:
use HeapAlloc to create a smaller page (page size and number of pages as caller arguments)
use memory-mapped temporary file
use a small structure to keep track of several requests (8 is probably plenty)

function 2:
select the "visible" page
memory-mapped temp file page swap

funtion 3:
close everything and clean up

[hutch--]

Here is the problem with using virtual memory to back up physical memory, where it fits into physical memory the operation may be reasonably fast but target an address that resides on disk and the speed will drop to disk access times. Now the point is well taken that if your usage is confined to the address range that is already in memory the speed will be a lot better but that can be slowed down as well by page thrashing, IE sequentially addressing locations that are not within the cache.

Now interestingly enough a quick sort can fit into that category in the early stages of its pivot selection if the data set is large enough, it will drop as the sort progresses until its fully within the same memory page and somewhere within the sort design this is where you swap to a simpler sort to finish it off, last I remember an insertion sort was the quickest on small counts.

[DanWebb314]

must be working on Euler
i need to do a few more to get my 25   

I am for the time being finished with Project Euler.  I quit because I had to get help for 3 problems to get 28 solved.  I started working on this problem after I was done with Euler.