Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Stack overflow with PACK statement in new V15 compiler

Andreas_Rost
Beginner
507 Views

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 
 

0 Kudos
9 Replies
Steven_L_Intel1
Employee
507 Views

We're going to need a test case - I tried creating one from your excerpt and it worked fine.

0 Kudos
Andreas_Rost
Beginner
507 Views

Hi Steve,

Thanks for answering.

I've attached a VS2012 Intel Fortran project, which reproduces the stack overflow.

Compile, debug & enjoy :-)

I hope this helps...

Regards,

Andreas
 

0 Kudos
Steven_L_Intel1
Employee
507 Views

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.

0 Kudos
Andreas_Rost
Beginner
507 Views

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...)
 

0 Kudos
Steven_L_Intel1
Employee
507 Views

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.

0 Kudos
Andreas_Rost
Beginner
507 Views

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


 

0 Kudos
Steven_L_Intel1
Employee
507 Views

Yes, that would be fine.

0 Kudos
Andreas_Rost
Beginner
507 Views

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
 

0 Kudos
Steven_L_Intel1
Employee
507 Views

I asked Ron to follow up with you.

0 Kudos
Reply