char(:), allocatable array initialization triggers access violation (for file i/o)

abhimodak · ‎01-19-2018

Hi

Please see the snippet below. Here is what I find: with 2017 update 4, it will always crash (at the internal file read). With update 5, 6, and 2018-update 1, the exe may run the first time. Try to run it again and it will fail. Try running it again and again and once in which it will succeed.

Abhijit

----

      Program Test

         ! Purpose: Demonstrate the IVF 2017 update 4, 5, 6, and 2018 update 1 compiler bug(?)

         Implicit None

         Integer, Parameter :: cStngLen = 16
         Integer, Parameter :: nE = 9 ! for any value of nE > 8 there will be access violation at read statement

         Character(:), Allocatable :: SomeArray(:)
         Character(3) :: OM
         Integer :: J

         Allocate(Character(cStngLen) :: SomeArray(nE))
         SomeArray = ' '
         ! Loop initialization would be ok.
         !do i=1, NE
         ! SomeArray(i) = ' '
         !end do

         OM = '012'
         Read(OM,*) J ! Will fail here
         Write(*,*) J

      End Program Test

andrew_4619 · ‎01-19-2018

I built and ran your code in debug and release on 18.0 and it ran OK. Post your buildlog so we can see what options you are using.

abhimodak · ‎01-23-2018

I am simply using ifort and with the versions mentioned in the original post.

Abhijit

andrew_4619 · ‎01-23-2018

When you build in ifort in visual studio you get a buildlog.html file. This shows the options (of which there are many) that were used. With that information your test can be repeated by someone else. I expect this problem will be with some other software on your system AV/ drivers etc that is causes the problem but you can only know it is some specific issue with your system if others can build OK with the same settings.

Steve_Lionel · ‎01-23-2018

Andrew, note that this is the Linux/MacOS forum... (I see the thread got moved.)

I can reproduce the behavior with 18.0.1 if I build with /check (on Windows) I haven't been able to narrow down the particular suboption as the error doesn't occur for every run. The symptom is that the program will (usually) display output but then Windows will report that it stopped running without giving a specific message.

Johannes_Rieke · ‎01-23-2018

Hi Abhijit, more information would be helpful as Andrew wrote. I remember a similar issue with allocatable character variables in the Linux forum, which I could reproduce in Windows also:

https://software.intel.com/en-us/node/742974

It might be related and still produces a segfault with 18.0.1.Only for certain lengths the segfault arises. The mentioned GLIBC relation is a red herring, I think.

The code of #1 from Abhijit fails at my workstation also (Haswell-EP, Win7 x64).

Build Log  
     Build started: Project: character_seg_fault, Configuration: Debug|x64 
 
Output  
    Deleting intermediate files and output files for project 'character_seg_fault', configuration 'Debug|x64'.
Compiling with Intel(R) Visual Fortran Compiler 18.0.1.156 [Intel(R) 64]...
ifort /nologo /debug:full /Od /warn:interfaces /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc140.pdb" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c /Qlocation,link,"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\bin\amd64" /Qm64 "D:\02_Fortran\99_test\character_seg_fault\test.f90"
Linking...
Link /OUT:"x64\Debug\character_seg_fault.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"x64\Debug\character_seg_fault.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"D:\02_Fortran\99_test\character_seg_fault\x64\Debug\character_seg_fault.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"D:\02_Fortran\99_test\character_seg_fault\x64\Debug\character_seg_fault.lib" -qm64 "x64\Debug\test.obj"
Embedding manifest...
mt.exe /nologo /outputresource:"D:\02_Fortran\99_test\character_seg_fault\x64\Debug\character_seg_fault.exe;#1" /manifest "x64\Debug\character_seg_fault.exe.intermediate.manifest"

character_seg_fault - 0 error(s), 0 warning(s)

Johannes_Rieke · ‎01-23-2018

If you change

SomeArray = ' ' to SomeArray(:) = ' '

all elements are correctly initialized. The left version initializes only the first element in SomeArray (write and debug in watch window). Strangely, the segfault in line 'Read(OM,*) J ! Will fail here' is gone then. Is something mixed up in memory?

More strange, I cannot reproduce the error anymore after a not failed run. Double checked, that I use the original code.