direct-access I/O to unit open for keyed access

[domel07]

While executing the following program linked to ACML math libraries and executing it on an AMD I get an error "direct-access I/O to unit open for keyed access":

PROGRAM TEST
CHARACTER(100) :: KEY, INPNAME='cylinder2D_steady.inp'
PRINT *, INPNAME
OPEN(2, FILE=INPNAME, ACTION='READ', IOSTAT=IO)
IF(IO/=0) PRINT *, 'ERROR OPENING '//INPNAME
READ(2, *, IOSTAT=IO) KEY
CLOSE(2)
END PROGRAM

Compilation line on the AMD:

ifort -O3 -xO TEST.F90 -L /home/dominik/pack/acml-4.1.0/ifort64_mp/lib -lacml_mp

Also, using a threaded version / compiling with -openmp or not seems not to make any difference.

Any idea what the problem is? Is it pure ACML problem or some vulnerability in ifort is exposed?

[Steven_L_Intel1]

Since this program uses IOSTAT but never displays the value, how do you know what error it is getting? Please show me the full output from a build and run of this program (and show the code by doing a "cat" of the file before the compile. Also, as this program does not call ACML, what happens if you leave ACML references off of the ifort line?

[domel07]

OK these are leftovers from the real code and have nothing to do. Cleaner version below:

PROGRAM TEST
CHARACTER(100) :: KEY, INPNAME='cylinder2D_steady.inp'
PRINT *, INPNAME
OPEN(2, FILE=INPNAME, ACTION='READ', IOSTAT=IO)
IF(IO/=0) THEN
PRINT *, 'ERROR OPENING '//INPNAME
STOP
END IF
READ(2, *, IOSTAT=IO) KEY
IF(IO/=0) THEN
PRINT *, 'ERROR READING '//INPNAME
STOP
END IF
CLOSE(2)
END PROGRAM

The file I am reading: cylinder2D_steady.inp:

MESH
cylinder2D_a.h5
SOLUTION
cylinder2D_steady_sol
RHO
1.D3
ETA
1.D-3
NLMAXITER
100
NLTOL
1D-9
CONVECTION
1
BC
CHANNEL
1.D-3 0
URF
1
STABILIZATION
0
ALPHA
-1
#TIME_STEP
# 10.D0 1000 10

The error I am getting on the command line at run time:

forrtl: severe (258): direct-access I/O to unit open for keyed access, unit 2, file /usr/almagell/itis1/dominik/data/test-solve/cylinder2D/cylinder2D_steady.inp
Image PC Routine Line Source
libacml_mp.so 00002B5FECC94116 Unknown Unknown Unknown
libacml_mp.so 00002B5FECC93316 Unknown Unknown Unknown
libacml_mp.so 00002B5FECC6F92A Unknown Unknown Unknown
libacml_mp.so 00002B5FECC5684C Unknown Unknown Unknown
libacml_mp.so 00002B5FECC55DB4 Unknown Unknown Unknown
a.out 0000000000402CF5 Unknown Unknown Unknown
a.out 00000000004012F3 MAIN__ 9 TEST.F90
a.out 00000000004011D2 Unknown Unknown Unknown
libc.so.6 000000312A91C3FB Unknown Unknown Unknown
a.out 000000000040111A Unknown Unknown Unknown




And yes, you are perfectly right: I am *not* calling anything from ACML, just linking to it. Not linking to it does not result in any error. So my guess is there is a bug in ACML that reveales a vulnerability in ifort. But it is too early to draw solid conclusions, that is why I post this issue.

Thanks for any insight.

[domel07]

... and of course, in the real program I *want* to call ACML, but I get the mentioned error before I am able to make this call. That is why I have to link to ACML.

[Steven_L_Intel1]

Truly bizarre. I'll have to get a copy and see if I can reproduce this.

[chipf]

This is a strange problem. The ACML support team is able to reproduce this problem. No ACML functions are called, yet the executable is changed enough to cause the problem.

Here's what I've found so far:

It's interesting that the two programs have much different symbol maps, with .hash and .dynsym being much larger when ACML is not linked in.

Because of this, the .text sections are at much different locations. But the code can be directly compared in two windows. I see that both get to for_read_seq_lis+500 in the same state. But right there, the code does a read from 0x2b0(%rcx). RCX is different in both cases, but that's due to the start of some section being different. You can dump memory starting at rcx, and they both compare the same (with some obvious addresses being different) until +0x1f0. Then the ACML linked version has the same data as

the other, but 0x20 earlier in memory.

But the code is reading at the same offset. You can see that the data at 0x2b0 is not the same, and is the name string for the input file.

I'm happy to collaborate with anyone assigned to look at this problem. It seems like something is wrong with the ACML build. If we can figure out what that is, AMD can resolve the problem.

[Steven_L_Intel1]

I suggest that you file a support request with Intel Premier Support. Include a pointer to this discussion and also provide a pointer to where ACML can be obtained.

[Steven_L_Intel1]

This turned out to be a problem caused by the way that the ACML libraries are built. Both the static and shared-object libraries have the Intel Fortran run-time libraries included, and the version used was 10.1. When you compile a program with 11.0 and link against ACML, it finds the ifort library routines in ACML instead of the ifort-supplied folder. Linking to older versions is not supported and can cause problems, though why this particular symptom should appear, I don't know.

AMD says that they will resolve this in a future update. Workarounds include linking against the .a static library. (For some reason, the static library does not trigger the problem.) See here for more information.