VS2010 stopped working (crash) when debugging attached code sample

[Jonathan_H_5]

When I Debug the attached code with VS2010 and IVF XE2013 (and 2011 on colleagues machine) on entering the subroutine SCALC, after a break point has been placed at line 448, causes Visual Studio (VS) to stop working (crash).  Debugging VS in another instance of VS states that a buffer overrun in devenv.exe has corrupted the programs internal state.  With no break point, or in Release mode, the program executes and terminates normally.

This code is from a large legacy Fortran program (650+ routines) and I have distilled down to just a few lines to demo issue.  The original code is characterised by very large argument lists being passed between subroutines.  However, it has been compiled with IVF for many years without issue.  Although I agree that the code style is legacy and ugly I do not think it breaks any basic rules.  I have checked that the argument list between the calling program and SCALC is consistent.  I tried varying the size of argument FEF (hardcoded to 100) and found that the code debugs normally if set to 99.  However, it could also be increased if the argument position was changed.  i.e. This seems like a real flaky memory issue but I cannot see anything wrong in the code and so I am starting to wonder if it is from the development environment.

I attach the VS project and source file: crash.f - please see if you can verify.  i.e.  (1) Open project with VS, (2) Insert a break point at line 448, and see if you can (3) Debug to this break point without crash.  If your test also crashes I would be grateful if you have any suggestions.  Jon

[Kevin_D_Intel]

Hi Jon - I will try this on my system and let you know the results.

[Kevin_D_Intel]

My apologies for the delay.

I can reproduce this crash using your steps.  For me, the VS 2010 IDE also crashes with a break set at line 249, running to that breakpoint and then simply trying to set a breakpoint at line 448, so in this case it does not even require attempting to step execution into the subroutine.

I also found debugging is successful (without a crash) with VS2012 and VS2013 using your steps and what I mentioned above also fails for me.

I happened to use our integration components from our upcoming PSXE 2016 (i.e. 16.0 compiler) release and expect yours are an earlier version on each of the two systems you tested. That suggests the crash is not dependent on a particular version of our integration components. It could mean our components are not at play, I don’t know yet.

For reference, I am using VS2010 Premium, Version 10.0.40219.1 SP1Rel. It includes ENU Service pack1 (KB983509)

I submitted this to our IDE team for help with further analysis and perhaps finding a work around as I was unable to find any sequence for getting into the subroutine and avoiding crash.

(Internal tracking id: DPD200374528)

[Jonathan_H_5]

Hi Kevin. Thanks for the sanity check. We are considering switching the legacy program architecture to use F90 modules (hopefully as a workaround) but a better understanding of the root cause from your IDE team would be welcome. I also append a few details of my system for interest. Thank you. Best regards, Jon

Dell Precision M4800 i7-4810MQ 4 Core with 16GB RAM.
MS Windows 7 Professional SP1.
MS Visual Studio 2010 Professional Version 10.0.30319.1 RTMRel.
MS .NET Framework Version 4.5.50938 RTMRel.
Intel® Visual Fortran Composer XE 2013 Update 2 Integration for MS Visual Studio 2010, 13.0.3615.2010.