forums.silverfrost.com

KennyT · Joined: 02 Aug 2005 Posts: 317

Hi

I have an intermittent error allocating a structure under win7-64bit that doesn't appear to be a problem under win7-32bit. It's quite a large complex structure (about 30Mb). I'm currently using v5.5 but have also tried v6.2. The symptoms are slightly different under each version:

v5.5: no debug, allocation fails 9 times out of 10.
v5.5: debug, allocation fails 5 times out of 10.

v6.2: no debug, allocation fails 9 times out of 10.
v6.2: debug, allocation hasn't failed (yet!).

The call is a straight "ALLOCATE(CO,STAT=IST)" where "CO" is defined as a POINTER to a structure. If I remove the "STAT=IST", the crash message is "Error 408, ALLOCATE was unable to obtain sufficient storage".

Any recommendations for debugging this? Can I verify how much memory is being requested by the allocate call before it is called, just in case some other parameter in the structure definition is making it request ginormous amounts of memory under some other circumstances?

TIA

K

PaulLaidler · Posted: Wed Jan 11, 2012 2:55 pm Post subject:

The problem probably reflects the differing amounts of memory available.

You can work out how much memory a structure uses if you assume the fields are packed in a minimal way. You can also use the FTN95 intrinsic LOC to get the address of the first field etc. The keyword SEQUENCE can be used to make sure that the fields are ordered as presented in the code.

I think that a Fortran INQUIRE statement can be used to get the size of a structure for reading and writing and that would do the trick.

KennyT · Joined: 02 Aug 2005 Posts: 317

Almost a year to the day since I asked the same question Embarassed

!!

K

edit: OK, the size of the structure is 58774769 bytes. The 32-bit machine that the allocate succeeds on has 3GB RAM plus a 3GB paging file (with 2Gb in use at the time of testing). The 64-bit machine that it fails on has 6GB RAM with a 3GB paging file (with 3.4GB in use at the time of testing)...

So, I don't think it's down to amount of available RAM...

Any other ideas what could be the cause? Is the "odd number" of bytes in the structure likely to be causing some grief?

K

2nd edit: Odd bytes doesn't seem to be the cause. I rounded the structure size up to 58774776 (so it's a multiple of 8bytes) but it didn't help.

K

3rd edit: Increasing the "stack" value in the slink script for the .exe seems to help! Yep, that seems to have fixed it! What's the default "stack" value?

K

4th edit: OK, the documentation says the default stack is 96MB (=0x6000000) but when I specifically set this value in the link script, it started working. Now, if I let it default, it also works! I'm very... Confused

K

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Allocate will try to find space for the structure on the heap not the stack, so your problem should not depend on the stack size limit.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl

PaulLaidler · Posted: Thu Jan 12, 2012 9:32 am Post subject:

The total heap size available will depend on the debugging options.
You get less for /debug, /check etc.

Also the total heap required by your program may be for more than just this structure.

KennyT · Joined: 02 Aug 2005 Posts: 317

Well, I really don't understand why specifying the stack size is having an effect on the ALLOCATE call then, but it does!

K

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

Do you allocate the structure more than once ?
You can re-allocate a pointer, without de-allocating the previous allocation.
This may be the source of the (loss of available memory) error.
While /check provides less memory available for allocate, there is still about (roughly) 1gb available, so 50 mb should not be an issue.
There can be a problem with /check with repeated use of allocate / deallocate.

John