Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26745 Discussions

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

New Contributor I


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.



      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




0 Kudos
6 Replies
Honored Contributor I

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.

New Contributor I

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


Honored Contributor I

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.



Black Belt Retired Employee

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.

New Contributor III

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:

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 
    Deleting intermediate files and output files for project 'character_seg_fault', configuration 'Debug|x64'.
Compiling with Intel(R) Visual Fortran Compiler [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"
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)



New Contributor III

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.