Can you post a complete program that exhibits this behaviour?

My first hunch at a report like yours is that somewhere in the program you have
an access violation (array subscript out of bounds or the wrong number of
arguments to a routine etc.) and this causes a corruption in the internal
data. The problem surfaces much later.

Another clue that this is happening is that it all works in debug mode but not
in release mode.

One possible mehod to hunt down the place where the actual damage is done
is to deallocate the array earlier in the program and then stop - or to comment out
parts of the program and see whether the crash disappears.

Regards,

Arjen

I concur with Arjen. Looks like something is stomping on the internal structures.

What happens if you ALLOCATE, do something innocuous with the data (so code optimizer does not eliminate code), then DEALLOCATE. Do not assume the code you currently run is innocuous.

If this works (DEALLOCATE without crash), then remove the call to the innocuous code, remove the DEALLOCATE and insert the DEALLOCATE in your code halfway to where you experience the crash. Then depending on if DEALLOCATION error occures or not, move the DEALLOCATION either closer to the end or beginning. Keep track of where you move it (e.g. leave tracks in code as comments). What you are doing is a binary search for point in code where corruption causes (future)deallocation error.

Don't be surprised if bug dissappears while looking for it.

Jim Dempsey

Wu,

What I suggest you do is to submit a problem report to Premier support with basically a copy of your above post.

Ask them to provide you with diagnostic code that will dump the contents of the array descriptors. Note,you want both the arraydescriptor of the array of your types and each array descriptor within each element of your array of types.Run a test producing dump of array descriptors with the method the code works and a second test with a dump where the code fails. Use WinDiff if problem isn't apparent at first glance.

I suspect something is wrong with how the array descriptors are initialized (or there is a side effect that disturbs the(an) array descriptor after initialization.

The first response you get from them is usually"Can you provide us with a small reproducer". Kindly explain to them you said in your first postyou tried and you cannot.Then you ask them "What would you use to diagnose corruption of an array descriptor? I am willing to help you to diagnose this problem, I suspect this is a case of array descriptor initialization or corruption but I need your help in dumping the contents of an array descriptor and identifying what I see. Let's work together to solve this problem."

While you have a work around, you would like the problem fixed because this problem may exist elsewhere in your code but the symptoms haven't caused the problem to be noticed (yet). One such problem with hidden symptom would be if the problem did not cause a crash but instead caused a memory leak. A worse problem would be an unnoticed corruption of the heap resulting in multiple objects allocated to overlapping addresses. I think you have identified a serious problem and it warrants a little bit of extra effort to diagnose and correct. The support person should understand this and work with you to correct this problem.

Jim Dempsey

You don't need to submit a report quite yet. Use the attached and see if it helps you at all. Note that the "A0 offset" is no longer used for that purpose, so it will look strange. It will be zero unless the variable is polymorphic.

Steve,

Thanks for attaching the array descriptor dump code. Will save it for a rainy day. It will be interesting to see if Wu discovers anything interesting.

Jim

I am also experimenting a hard crash when calling deallocate on an allocatable array which belongs to a derived type. I am also using SSE2 but disabling it does not change the behavior.

The type is:
type :: RPT21DARR
real, allocatable :: p(:)
end type RPT21DARR

The variable is:
type(RPT21DARR) :: sk_2s(30)

The call which crashes:
deallocate(sk_2s(1)%p,STAT=ir)

Calling LOC on sk_2s(1)%p gets: 96031592 which is 5B95368 in hex.

Dumping the array descriptor of sk_2s(1)%p just before the crach using the routine provided by Steve I am getting:

Dump of descriptor at location 05DEECA0
Base address: 05B95368
Element size: 4
A0 offset from base: -4
Flags: 00000005
Defined
Contiguous
Rank: 1
Dimension 1: LB 1 Extent 3005 Stride 4

The length is 3005 (as allocated). Do you see anything abnormal in this dump?

Thanks,
Rak

And the error message for the crash is... ?

Quote:

Steve Lionel (Intel) wrote:

And the error message for the crash is... ?

No error message at all. Just the Windows trace for an application crash:
Problem signature:
Problem Event Name: APPCRASH
Application Name: .emme.exe
Application Version: 0.0.0.0
Application Timestamp: 50ad4311
Fault Module Name: ntdll.dll
Fault Module Version: 6.0.6002.18541
Fault Module Timestamp: 4ec3e39f
Exception Code: c0000005
Exception Offset: 0002a43e
OS Version: 6.0.6002.2.2.0.256.6
Locale ID: 1033
Additional Information 1: fd00
Additional Information 2: ea6f5fe8924aaa756324d57f87834160
Additional Information 3: fd00
Additional Information 4: ea6f5fe8924aaa756324d57f87834160

Anyway, it seems that I have isolated the problem. It appears only when I use inside a OpenMP parallel DO a variable declared as:

type(DPPT22DARR) :: ycaddmk(MCLS_)
where MCLS_ is a parameter (30).

The above type is defined as:
type :: DPPT22DARR
double precision, allocatable :: p(:,:)
end type DPPT22DARR

The usage of the variable is either as:
ycaddmk(m)%p(i,j)=bla

or directly a matrix operation:
ycaddmk(m)%p=MyMatrix+MyScalar*ycaddmk(m)%p

I am trying now to reproduce it in a small project (hopefully I will be able to).

As a work around for the first usage, I created a temporary matrix and copy in/copy out ycaddmk(m)%p before/after the parallel DO (luckily the DO loop is over variable j). Unfortunately, I cannot do the same thing for the second example where the DO loop is over variable m :-(

Thanks Steve,
Rak

The crash is an access violation. You might be exceeding the thread stack size - try defining the environment variable OMP_STACKSIZE to be some larger value (10000000 or such).

Quote:

Steve Lionel (Intel) wrote:

The crash is an access violation. You might be exceeding the thread stack size - try defining the environment variable OMP_STACKSIZE to be some larger value (10000000 or such).

100% sure it is not that (I've got it in the past and the behavior was different. It has been already set to a higher value anyway, and increasing it more didin't solve the problem.

I started constructing a simple program to try to reproduce the problem but I run now into a compiler bug (depressing...). I am attaching the VC2008 project file which issues the message: "1>fortcom: Fatal: There has been an internal compiler error (C0000005)." It practically contains only one *.f file. Note that this does not reproduce the crash but I cannot even compile.

Perhaps more depressing: when I pressed upload, I've got an HTML AJAX error I will try to attach the JPEG screen-shot. Anyway, I am far more interested by the FORTRAN problem which is kind of show stopper of our current project than the HTML one.

Thanks Steve,
Rak

As expected, the upload didn't work as expected.

Project to reproduce the compiler bug.

I can't reproduce the compiler failure with the version you cited (2011 Update 4). But when I look in the build logs, I see you are actually using 11.1.048, which is considerably older! Please try it with a newer compiler.

Quote:

Steve Lionel (Intel) wrote:

I can't reproduce the compiler failure with the version you cited (2011 Update 4). But when I look in the build logs, I see you are actually using 11.1.048, which is considerably older! Please try it with a newer compiler.

Hi Steve,

just to let you know that upgrading the compiler to the latest version solved both problems:
- the original one (mishandling arrays of allocatable arrays/pointers inside OpenMP do loops)
- the compiler crash inside VisualStudio when building a small example using allocatable arrays/pointers inside OpenMP do loops

Thanks,
Rak

Glad to hear it. In the future, please double-check the compiler version you are using before writing up the report. I don't mind a report against an old version, but it saves both of us time if you name the correct version.