Application works from VS2008 GUI, but fails when run as a stand alone console application

[rniswon]

I've had a very hard time tracking down an 'access violation' exception when running an application built in XE 2011 ver 12.0.x. The problem went unnoticed due to the fact there seemingly was no problem when running the fortran code from the visual studio 2008 GUI. Recently, however, I tried running the executable directly from a windows console application and got an access violation error. Based on suggestions from another forum (one of which was to post on this forum instead), I have tried the following:

1) right-click the executable and run it as an 'administrator'

2) from the debug menu, select 'exceptions' and switch 'on' pertinent exceptions since nearly all default to an 'off' status (I've even gone so far as switch nearly everything on)

3)right-clicked the project (from the Solution Explorer in Visual Studio), selected: Properties -> Linker -> System and bumped up "Heap Reserve Size" "Heap Commit Size" "Stack Reserve Size" & "Stack Commit Size" to 10^9 (previously 0).

4) constantly "cleaning" the solution (from the debug menu) and rebuilding it after each tweak to the code.

None of this has led to a final solution, however. Addtional items I have noticed are that and combination of 32-bit/64-bit and debug/release mode works when run from the GUI, but only the 32-bit debug-mode executable works when run from a console, and its much too slow for what I need it for (I really need to get a 64-bit release mode executable that works!). Since the debugger doesn't alert me to the problem, I've tried inserting WRITE statement throughout the code to clue me in on where it crashes, only to find out that by inserting write statements in different places causes the code to crash in different places. Baffled, I then tried contacting Intel support, only to land on the dreaded screen: "We are experiencing technical difficulty, we have alerted personnel and are sorry for the inconvenience."

So, alas, I'm turning to this forum as a last ditch effort to find a solution...how can I solve this problem?

Using the following:

1) Windows 7
2) MS VS2008 Version 9.0.21022.8 .NET Framework version 3.5 SP1
3) Intel Visual Fortran Composer XE 2011 Integration for Microsoft Visual Studio* 2008, 12.0.3470.2008

[rniswon]

Hi Steve,

Thanks so much for digging into this. Did the solution I sent you have the same problems with not stopping at breakpoints in 64-bit debug mode? For some reason this is still an issue for me.

Regarding IETFLG, its now LOGICAL and is/was definitely getting set with the following code starting on lines 155of mt_ssm5_updated.for:

IF(FUZF) THEN

READ(iUnitTRNOP(6),*,ERR=100,IOSTAT=IERR) LINE

IF(LINE(1:1).EQ.'#') THEN !READ NEXT LINE

READ(iUnitTRNOP(6),FMT2) NUZTOP,IUZFOPT,IRUNFLG

& IETFLG

ENDIF

ELSE

IETFLG=0

ENDIF

I need to make this code more robust before release, but in the example I attached a few posts up it will either get set as IETFLG = 1, but even if this wasn't the case then it would for sure get set as 0. I have removed IETFLG from line 118, the line you pointed out as using a variable that had not yet been set.


I need to look into IFMTRF some more, but it does get set with a number of other variables in line 554 of mt_btn5_updated.for:

READ(IN,'(4I10,L10)') IFMTCN,IFMTNP,IFMTRF,IFMTDP,SAVUCN

I'll look more into why POINTER was used instead of allocatable. Perhaps this can get swapped around, I'll find out. Finally, for the instances:

ALLOCATE(UZFLX(1,1,1))

ALLOCATE(UZQSTO(1,1,1))

ALLOCATE(SURFLK(1,1,1))

ALLOCATE(CSURFLK(1,1,1,1))

ALLOCATE(FINFIL(1,1))

ALLOCATE(CUZINF(1,1,1))

ALLOCATE(UZET(1,1,1))

ALLOCATE(CUZET(1,1,1,1))

ALLOCATE(GWET(1,1,1))

ALLOCATE(CGWET(1,1,1,1))

these variables are not used for the circumstance where the code drops into the if statement surrounding these allocate statements. Because they are deallocated whether or not they get used, I chose to just allocate them with 1,1,1 instead of NCOL,NROW,NLAY as place holder. Perhaps there is a better way to do this as well. I look into it some more. Finally, if you could let me know more about the debugger option in the solution I attached above, that might help me sort out why mine doesn't seem to work.

[rniswon]

Hi Steve,

The executable is now working! It must have been the IETFLG discrepancy you pointed out, because that's all I addressed before retrying the .exe. For the model I've been running the exe doesn't use reactions (which is where IFMTRF is used) and is likely why that bug isn't causing a problem for the example model I'm testing the code on. I'll be sure to clean that up.

Thanks again, this is a huge load of my mind.

The only other thing is if you can share with me anything you might know on how to get the debugger to recognize breakpoints, that'd be great.

Eric

[Steven_L_Intel1]

I had no trouble with debugging for X64. But the project as you sent me had disabled all of the debugging options, so I had to re-enable them. That probably explains the problems you had. You will need to set Fortran > Debugging > Debug Information Format to Full, and Linker > Debugging > Generate Debug Info to Yes.

I agree that IFMTRF does not seem to be a problem. If I remove the test on IETFLG at line 118, then the program seems to run ok whether or not in debug mode, so that is probably the key issue.