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?

[Bernard]

So the problem probably originates in Fortran system code?Manually debugging with the VS debugger will not help us at least to understand whose handle is corrupted.If you could create minidump file and upload it.

[andrew_4619]

Yes that why I think a need to pair down the project and send it to intel. I'll have a further look at it when I get back home in a couple of  days unless I get bored in a hotel somewhere....

[Bernard]

I am still not sure if the problem is caused by Intel fortran compiler,but I do not  exclude such a possibility either.As I mentioned in my previous post a full process minidump could be very helpful in order to find where the problem originates.

[andrew_4619]

I did some work on this last night with some very surprising results.

I copied all the source files and made a new project with the intention of eliminating bits of source code step by step until the problem went away. But the application build and ran with NO problems!. I found some compiler settings were not the same in the new project so  some changes later they were identical and it still worked! I note there are some differences on the linker command line that I need to investigates and it is not also beyond the realms of possibility that  library paths could be an issue (versions of library found that is linked to).

I haven'y checked the help yet but is there a verbose mode for the linker that shows the paths of libraries that are used?

[Steven_L_Intel1]

/verbose:libs is the linker option. In VS, it's "Show Progress > Show some progress messages".

[Bernard]

@app4619

Congratulations on solving the problem.

[andrew_4619]

I have attached a zip with two build logs. There are two different projects that contain exactly the same source files, one is the 'old' project and one the 'new' project (called qwin1), both in the same solution is vs2010 shell.

The are both built with exactly the same compiler options on the latest compiler revision and build with no errors. The link commands are slightly different as:

The Old project uses relative path and has /LIBPATH:"." in the build.

The new project has absolute paths and has /IMPLIB:"C:\Users\....\QWin1\Debug\QWin1.lib" added (it did this by default). Qwin1 is the project name but this lib is not created by the project and does not appear to exist.

I have the verbose option on the linker and it appears (as far as I can see) that exactly the same libraries are used in the link.

Project old generates an exception (handle error in _for__release_lun() ) (as described earlier in this topic) on the first Fortran open (and all others as well)  but returns no Fortran error from IOSTAT.

Project New runs fine, no problems. On the old compiler (update 5: XE 13.1.3.198) both projects build and run OK. 

Anyone got any explanation? I makes no sense to me. Clearly I can make a new project and it works but this leaves me unhappy as  things not working for no explained/logical reason is very worrying.

[Steven_L_Intel1]

I don't see anything obvious. Ignore the /IMPLIB setting - that gets used only when generating a DLL. An interesting experiment would be to copy the failing project to a new folder and do a Rebuild there. Same problem? I wonder if you have something on the system corrupting your EXEs.

[andrew_4619]

@steve not tried your suggestion yet but I have noted that in the failing project 1 source file (getfileopen..) generates an .asm file but when I look at the build properties for that file for that file I note that no asm listing is asked for. BUT the command line for that file is different (a couple more warning diagnostics are excluded) AND its appear to have  /Fa"Debug/" in the command line!

So I removed the source file from the project.

Closed VS saving the project

Opened  VS and the solution

Added existing source file (the missing one) and build. It compiles with no ASM generated.

I then customised the properties for that file to suppress warnings about 6463 and 7410 and recompiled and I now get as assembly listing! But the is no FA entry for the command line in VS for that file.

Is this project just messed up?

[Steven_L_Intel1]

Interesting. Please attach the .vfproj file so I can take a look.

[andrew_4619]

the Vproj is attached, it is xml?

[andrew_4619]

hmmm looked at that in notepad there are a mess of configurations release/win32 and debug/win32 are the only used ones.

[Steven_L_Intel1]

I see what is happening. The project has a sort-of non-default value for the assembly output directory, and even though no assembly listing is asked for, the IDE adds /Fa to specify where one should be placed and this causes the listing to be created.

To fix this, temporarily change the Output File > Assembler Listing value to Assembly Only. Change ASM Listing Name to <Inherit from project defaults...> and then change Assembler Listing to <Inherit from project defaults...>

[andrew_4619]

Ah OK yup that problem has now gone away the original issue is still with me. Further tests required. 

[andrew_4619]

OK I left all the project files where they where an made a new project in the same solution and removed the old project. It builds and runs with no problem in debug and release for both compiler versions (XE 14.0.1.139 and XE 13.1.3.198).

After extensive tests I cannot find any reason why the old project fails. The only difference I have found is that if you look at the verbose logs for the linker the old project cycles through the system libraries (Ifort/sdk etc) in a slight different sequence so it is possible that if some calls can be resolved from more than one library then a different code might result. If this were the case there is a bug lurking to bite again at some point.....

I seem to have wasted about 10+ hours on this so I give up and will just except that it now works

:-(

[IanH]

What's that deskey32.lib thing.  How does it end up being pulled into the link?

[andrew_4619]

It is an interface layer for a USB device, there are !DEC$ objcomment lib:"deskey32.lib" in the source and the lib is sat in the project folder. There is only one version of the lib on the PC other than a 64 bit version which has a different name which I think you can guess.