- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi guys,
another issue related to the new V15 version of your Fortran compiler.
The following statement worked fine up until the latest V14, but crashed with a stack overflow using V15:
REAL, POINTER :: BUFFRB(:,:,:,:)
ALLOCATE(BUFFRB(200,200,4,2))
mt_pklv = PACK(BUFFRB(1:200,1:200,1:4,2),.TRUE.)
Do you have any idea, what happened here. I guess, that PACK uses some temporaries on the stack instead of the heap and therefore crashes.
mt_pklv is an REAL vector huge enough to hold all elements of BUFFRB().
Thanks & regards,
Andreas
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We're going to need a test case - I tried creating one from your excerpt and it worked fine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This program is incorrect. The size of the result of PACK is 160000 but you allocate mt_pkl to 1235052. This is a shape mismatch which we, unfortunately, don't detect. The assignment then starts accessing unallocated memory.
The stack overflow can be avoided by setting the option Optimization > Heap Arrays to 0, but you'll then get an access violation (I saw this in 14.0 as well.) The better solution is to make the arrays ALLOCATABLE instead of POINTER, don't allocate mt_pkl and also set the option Language > Enable F2003 Semantics to Yes. This will cause mt_pkl to be automatically allocated to the correct size.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
your comment regarding the Heap arrays was the solution.
I set them to 0 and now it works - regardsless of whether mt_pkl is bigger than the vector produced by the PACK function.
I guess, that PACK tries to create a temporary, which by default lies on the stack.
Wouldn't it be better to create its temporary always on the heap to avoid such problems? (regardless of the heap arrays switch)
But anyway: I found the reasons thanks to your help.
Thank you very much!
Best regards,
Andreas
P.S.: I've got another still unresolved issue regarding V15:
https://software.intel.com/de-de/forums/topic/531020
Maybe you could have a look at it too? (Ron hasn't answered quite a few days...)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Enabling heap arrays will avoid the stack overflow, but it doesn't fix the program - the shape mismatch may or may not cause data corruption depending on how the compiler chooses the number of elements to move. If you make mt_pkl ALLOCATABLE, and enable "Fortran 2003 Semantics" (under Language), then that problem will go away. Indeed, use of ALLOCATABLE is preferable to POINTER unless you are using pointer assignment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
the test case was just a quick and dirty copy to reproduce the error outside my much more complex program.
mt_pkl actually isn't allocated inside my prog but points to an area of shared memory delivered by an DLL in order to allow inter-process comunication. That's why I can't use allocatable...
But as for your comment regarding shape mismatch I will change the assignment to something like:
mt_pkl(1:200*200*4) = PACK(BUFFRB(1:200,1:200,1:4,1),.TRUE.)
This should avoid the mismatch - don't you agree?
Regards
Andreas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, that would be fine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
as asked before: could you possibly have a look at this topic:
https://software.intel.com/de-de/forums/topic/531020
Ron hasn't answered for a week now and it would be great to solve this...
Thanks in advance,
Andreas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I asked Ron to follow up with you.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page