forums.silverfrost.com

[KennyT]

hi, could you email me that text block? when I copy/paste it, it won't compile (it's got some sort of illegal character (hex"A0") embedded in it)

K

[KennyT]

Hmmm, i don't think that works?

do you get different values returned by alloc if you call it more than once without dealloc-ing?

i'm experimenting with a "hybrid" solution that seems fairly solid but it depends on keeping a record of the start and end addresses allocated in a table.

basically, if the buffer size (to the nearest multiple of 16bytes) is large then i use GET_GSTORAGE@
if it's medium then i use GET_STORAGE@
if it's tiny then i use localalloc (via a STDCALL)

[mecej4]

That is strange, and may be related to the exact details of your copy-paste procedure. I used Firefox on Windows to copy, and pasted by redirection to a file in a command window, and did not find any characters with the high bit set.

I may note that it is not quite correct to use an argument to ALLOCATED that has not been declared to be allocatable. You should probably use ASSOCIATED instead. Similarly, NULLIFY instead of DEALLOCATE? The choice between pointers versus allocatables depends on what you want to do in your application.

[JohnCampbell]

[KennyT]

[KennyT]

[PaulLaidler]

Kenny:
If you send me a personal message with your email address then I will email you a copy of the code.

mecej4:
Yes ASSOCIATED is better and avoids the warning message. I will edit the post.

John:
For 64 bit applications you can access VirtualAlloc via GET_GSTORAGE@ or GET_GSTORAGE64@ but VirtualAlloc does not get heap memory. For further information Google "VirtualAlloc MSDN".

[KennyT]

[PaulLaidler]

I should have also tested the code for a 32 bit application. It works for 64 bits.

There is something wrong with addr = loc(arr). addr = loc(arr(1)) is better but still not right.

I will have to think again for 32 bits.

[JohnCampbell]

This is my contribution to understanding memory allocation

[JohnCampbell]

Kenny,

I find the combination of Fortran local, automatic and ALLOCATE arrays work well for me for /64. I limit my memory management to call by reference arrays, so do not use pointers or memory address as routine arguments (excuse this example!).
Other Fortran compilers that use non-contiguous arrays or temporary arrays for array sections, this can cause problems for my "F77 wrapper" approach.

https://www.dropbox.com/s/71zgzfenhfjcel7/mem_test2.f90?dl=0

This link to an expanded example shows the location and spacing of ALLOCATE arrays (which go to the heap) and local arrays (which go on the stack)

ALLOCATE is doing what I want, in that large arrays are being located on a new memory page (with a 64 byte offset, which I can cope with), while local arrays appear to be placed on the end of the stack.

Based on the example for allocatable components of a derived type, there appears to be some wastage of memory page addresses, although this is not an issue for /64, as they would not be allocated physical pages. The memory address is basically a virtual address and all that is important is the number of physical memory pages that are allocated to the program.

The use of local or automatic arrays can require defining a larger stack at link time.

Allocatable components of a derived type array are a good way to manage lots of allocatable arrays, although they must each be deallocated to avoid memory leakage.

[PaulLaidler]

Kenny

This works fine for me (for both 32 bits and 64 bits)...

[KennyT]

thanks Paul, that appears to work well, although i am still getting some "un-debuggable" run time errors, that i assume are due to errors in our fortran code (or the data being read being too big for the heap - is there a setting in the linker for this?). However, it is very difficult to use UNDEF to isolate these errors due to the persistence of runtime "error 14":

"Attempt to alter an actual argument that is a constant, an expression, an INTENT(IN) argument, or a DO variable"

which is still throwing up "false" errors.

is there a way to turn this error off (or at least let execution continue) so we can get to the true cause of the issue? there appears to be lots of choice about errors that can be ignored in the help but i can't decide which one(s) to use!

K

[PaulLaidler]

Kenny

You could try using

/inhibit_check 1 2

on the FTN95 command line but that may not be wise.

I am not really in a position to be able to provide advice on how to debug your code.

[KennyT]

i appreciate that, but the runtime error 14 is surely yours to try to address, given that we can clearly demonstrate that, in many circumstances, it's a false positive.

a switch to inhibit this error in the appropriate compilation would be enormously helpful, if you can't isolate what's causing it.

I suppose i could move the routine(s) that exhibit this issue into a source file that gets compiled /DEBUG rather than /UNDEF?

K