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.
! Purpose: Demonstrate the IVF 2017 update 4, 5, 6, and 2018 update 1 compiler bug(?)
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) = ' '
OM = '012'
Read(OM,*) J ! Will fail here
End Program Test
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.
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.
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.
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 Output Deleting intermediate files and output files for project 'character_seg_fault', configuration 'Debug|x64'. Compiling with Intel(R) Visual Fortran Compiler 18.104.22.168 [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)
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.