I have a fortran code compiled with Intel fortran compiler 2013 and VS2010 under windows 7 that started to give me unhandled exceptions without showing the line in which the code was crashing. Usually an error like this was showing up:
Unhandled exception at 0x73e1d3d2 in GRIB2METEOriparto.exe: 0xC0000005: Access violation writing location 0x00240ef4....
and the call stack had only dbghelp.dll or verifies.dll and no source available. I moved my source files under Cygwin, I compiled with gfortran with all the possible warning/error flags on (including check bounds and implicit interfaces) and no warning at all and the program runs smoothly. All interfaces are explicit cause I am using "CONTAINS". Therefore if there was a mismatching number of arguments the debugger would catch it. No uninitialized variables are present. I went back to VS2010, I did a "clean solution" and I rebuilt the project. The code started to crash inside different C routines (that I did not write) such as:
crt0.c at the line:
mainret = _tmain(__argc, _targv, _tenviron);
or
osinfo.c at line (if I well remember):
EnterCriticalSection( &(_pioinfo(fh)->lock) );
The code was not even reaching the first line of executable code (a breakpoint there was not reached).
I started commenting some lines of code I recently added in the past days and when running the thread was finally passing successfully the few first lines and it crashed at a subroutine call with a stackoverflow error. That finally helped me understand the problem. I have a bunch of characters declared as character*2560 (both in the subroutine and in the main code). I substituted them with character*256 and it was not crashing anymore. I rewrote character*2560 and I added the flag /stack:2000000 in the link options and now everything runs smoothly. I removed the extra comments I added in those line of codes (that where calling the faulty subroutine with too many character*2560) and everything runs smoothly. I recompiled everything with gfortran in Cygwin and everything is still good. Is this normal? Am I safe now? Was initially the stack overflow error for some reason wrongly interpreted as a access violation? Is that possible?
EDIT: this is my faulty declaration in the main program (I have similar ones (but shorter) in other subroutines):
character*2560 DOScallINV,FORMdosCALLtxt,FORMdosCALLinv,filenam,FILEinv,provSTR,FMTtimeMETEO,&
TIMEstring,fmtGRID,fmtTIMEstring,FMTdataMETEO,WORKINGdir,path,DIRgribs,PATHgribs,&
DIRresultsRUN,PATHoutput,previousDIR,filePATH,PATHresultsRUN,PATHinputD3D,textFILE,&
newLINE,textFILE1,textFILE2,PATHlogs,LOGfile,LOGdir,ilineTXT,message,PATHresultsREST,&
LastRUNfolder,PATHobs,PATHopenda,PATHresultsRUNm1,workworkWITHnum,pathSTOBS,pathSTMOD,pathALG,&
toBEfound,COLLECTdirect,COLLECTdirectLOC,PATHwork,filePATHtot,filePATHlong,stringCAL,string,&
pathNM,filePATH_d3model,CDstring,toBEadded,stringCALini,filePATH_d3wrapper,fileWIND,dudFILE,stringL,stringU,fileWINDcal,&
PATHweb,pathREGR,fileWEB,PATHfileANALYSIS,threadFILE,threadFILEcopy