debugger exceptions for fortran file I/O for XE 14.0.1.139

[andrew_4619]

I just installed  XE 14.0.1.139  which seemed to go OK. I did a clean solution and then a full debug build for X32 which  appeared to go normally. This is a Quickwin application BTW.

When running under debug in VS2010 shell I am getting "first chance exceptions"  for "Invalid handle exception for current stack trace". These are associated with every Fortran open statement, inquire statement and Quickwin routines that use a unit (eg open of a child window & setactiveqq...)

The units are always explicitly declared as 4 byte integer variables and are initialised with sensible numbers. Most of this is mature code that has been used for years.

 The exceptions are all continuable and the program seems to function correctly by the way.

Any clue as to what might be the problem?

[andrew_4619]

I take back the "the program seems to function correctly", it does under debug but in release the process appears in task manager but doesn't get past some on the initialisation as we do not get to display anything before the application process disappears without trace or error or exception!

Switching of optimisation has no effect. :-(

I little more floundering around to go and then I will have to do a full un-install and regress back to an older version :-( 

[andrew_4619]

I couldn't find any problem with my code, it is some issue related to handing file open in the Intel libraries I think. In debug the exception happens during the open command, all the parameters look good, and having ignored the exception (which must be handled) we don't  even get a fortran io error.

Uninstalling and going back to update 5 was a total pain as XE 14.0.1.139 had partially uninstalled update 5 which would not uninstall and a repair would not create vs2010 integrations. however after repair it would uninstall top allow a complete reinstall from the downloaded media!

It all works now but some insight into what the issue might be would be good as at some more opportune points I will need to move forward.

[Bernard]

While running under the debugger or probably when the program is compiled as a debug build the currently register debugger will be signaled by SEH about the caught exception and if the debugger does not handle that exception or simply returns the execution back to program.This is called first chance exception.

[andrew_4619]

The exceptions (invalid handles) all occur on call to the Fortran Open command the error it is triggered in my code it the the fortran library code. Further, it occurs on any and every open or inquire statement that had reference to a Fortran 'unit' number and "inquire" by file name does not generate an exception. In all cases the open/inquire have error handling and return zero (no error).

. The release version starts and terminates silently after a few seconds (it is seen in the taskmanager) without creating a window. No error, no traceback.

Out of interest I switched all optimisation off and then also tried heaparrays but the behaviour is unchanged.

Totally totally baffled.

As I have some work I need to do I have un-installed and revered to update 5. Can I have separate installs of the two versions on the same PC (using 2010 shell) to allow me to investigate more at my leisure?

[Bernard]

>>>. The release version starts and terminates silently after a few seconds (it is seen in the taskmanager) without creating a window. No error, no traceback>>>

This probably means that no suitable exception handler has been found and/or debugger was not able to handle the exception so the default OS procedure in such a situation is to terminate the process.

>>>The exceptions (invalid handles) all occur on call to the Fortran Open command the error it is triggered in my code it the the fortran library code. >>>

You can try to monitor your application with the help of Application Verifier coupled with debugger in order to catch and invetigate those invalide handles.As your code is compiled and executed in Windows environment I suppose that those handles are created by OS code which deals with the files(CreateFile() function).

[Lorri_M_Intel]

Are you using the /iface:cvf switch?  Sometimes that can cause stack issues.

Are you willing to share your project with Steve, so we can try and figure out what the underlying problem is?

                  --Lorri

[andrew_4619]

:@Lori No that iface:cvf stuff went a long time ago.  A question is that can XE 14.0.1.139 and XE13 update 5 co-exist on the same machine using VS2010 shell?  Or perhaps failing that I will install XE 14.0.1.139 on another machine of mine I believe the licencing allows this (A have a normal commercial single user licence).

I am reticent to share the project due to commercial sensitivity however creating a smaller sub-set  that creates the problem would be easy enough I think and better anyway. I can't do this at the moment as I had to uninstall XE 14.

There must be some wampy interaction either from my code with the runtime stuff or specific to my machine that causes this otherwise I would expect a thousand users would be heading  for Intel with pitchforks right now.....

Regards

Andrew

[Steven_L_Intel1]

Yes, the two versions can coexist and you can switch back and forth using Tools > Options > Intel Composer XE > Visual Fortran > Compilers.

[andrew_4619]

OK thanks, I am guessing it is a custom install and I have to tell it to keep the old version and integrations?

[Steven_L_Intel1]

Actually, no. Just install both versions normally. You get the later integration, but that allows you to select the older compiler.

[andrew_4619]

OK thanks Steve, a small observation not worth a thread,  the c_loc,, c_sizeof etc  do not get highlighted in blue in VS editor as like all the others intrinsic s do, even the non-standard ones. Is that deliberate or on omission? It would be nicer if they did. I suspect it is deliberate because they are module procedures. 

[Steven_L_Intel1]

I believe you are correct. We may want to revisit this in the future.

[andrew_4619]

[fortran]Program Main
    implicit none
    do while(.true.)
    enddo
    stop
end
function initialsettings()
    implicit none
    logical(4) :: initialsettings
    integer    :: iochk
    open(UNIT=77,file='log.txt'C,iostat=iochk) 
    initialsettings= .true.
end function initialsettings

[/fortran]

Having striped every thing away my Quickwin application only has one line of user written code that is executed, the open statement and this still causes the invalid handle exception (see attached jpg). 

The Project still contains 19 other source files and around 700 subroutines which get baked into the exe, I will try to remove things a bit at a time unit it works, but this might be hard work due to interdependencies.

[Bernard]

Can you post disassembly of the code around address 0x7775fba1? I suppose that at this address the already invalid handle is  used  by NtReadFile or NtWriteFile(invalid handle exception is probably thrown from KernelBase.dll).I think that variable which holds the integer value of handle gets corrupted somehow in the course of program execution.

[andrew_4619]

Iliya, I'm not sure that is going to help me a great deal, we are heading into territory that is rather beyond my knowledge, and is quite probably some unforseen or unusual  interaction within the Intel quickwin coding. Prior to the exception in my test case I haven't executed any of my coding, we are on the first executable statement!. I have attached a screen grab of the disassembly.

I am hoping to generate  a greatly reduced size project I can sent to Intel.

[andrew_4619]

I reattached the disassembly dump at the exception but with symbols loaded and also the call stack. This was the full program rather than the reduced program but the behaviour is identical.

[Bernard]

It looks like a indirect call into Thread Environment Block (TEB) structure which could probably cause the invalid handle error.The exception is thrown during stack cleaning (add esp,4) after function call. Later I will check with windbg what is located at FS:[0x0C0] address.

I suppose that error is not directly related to your program,although without seeing what is called at FS:[0x0C0] and inspecting its arguments nothing can be said about the culprit.It could be also system induced error mainly because TEB structure is set during process creation phase.

[andrew_4619]

@iliya: Thanks for input, I'll gave a further dig around it later perhaps, got to dash now to catch a flight to Paris.

My thought is is goes wrong in the fortran _for_release_lun   (lun=logical unit number) as all open and inquire statements that have a unit number crash, but for example an enquire by file rather than unit does not crash...

[Bernard]

Can you explain what cadfil.exe!_for__release_lun() + 1bc does? It seems that at this address  is called NtReleaseMutant which next calls itself. Afaik that function receives a handle to Mutant(Mutex) object which in turn is obtained from the call to NtCreateMutant.Could that handle be invalid?

Does your code call NtReleaseMutant? because it seems so by looking at diassembly where ReleaseMutant is checking SEH block.

You are right that we are stepping into Windows kernel territory which is scarcely documented.

[andrew_4619]

_for__release_lun()  is not my routine, it is part of the fortran system invoked via the "open" statement. fortran release logical unit number (the forttran "file handle") is my guess.