Mixed language crash problem

[gib]

This is a long shot, but somebody here might have a suggestion or two.

My 32-bit program has Fortran calling Saad's ITSOL library (C code) which calls BLAS and LAPACK (Fortran code).  I have built this with VS2005 + IVF 11.0.075, with VS2010 + IVF 11.0.075, and with VS2012 + Intel Composer XE 2013, all on Windows 7, and these programs all execute correctly (as far as I can tell).  I am now trying to get the program to work on Windows 10 with VS2015 + Intel Parallel Studio XE 2016.  I have rebuilt all the libraries, and built the executable.  It crashes without any useful info very early, in a call to a C function that does nothing but allocate 20 bytes of memory with malloc and return the pointer.  printfs before and after the malloc show that it is OK, so I'm guessing that the crash happens on the return to the Fortran calling subroutine.  In the Fortran (main program and the BLAS and LAPACK code) I have turned on Runtime error checking for Null pointers and allocatable array references, for Array and string bounds, for Unitialized variables, and for Stack frame.  None of these errors is caught, but the reason given for the failure is an unhandled win32 exception.  If I ask to debug I see this: "Unhandled exception at ##### (ucrtbase.dll) in scell_main.exe.  An invalid parameter was passed to a function that considers invalid parameters fatal."

I'm wondering where to look for the source of the problem.  It's puzzling that it has worked until now.

[mecej4]

Please post the Fortran source codes (and any C glue code that you wrote), plus data files, if any, and give a link to the specific version of ITSOL that you used, or specify the version number of ITSOL.

Does your Fortran interface to C through the ISO_C modules, or do you do it the old-fashioned way, with directives?

[jimdempseyatthecove]

Can you enable the stack trace?

Also, if this is a Windows Forms application with no console window, and your code is a DLL, then look at the Debugging forum for a recent post I made relating to this subject.

Jim Dempsey

[gib]

Jim, the Fortran is built as a DLL, which I can run in two ways, either from a Qt GUI or from a simple console main program.  The latter is for production runs on a cluster (Linux in this case), and is also more convenient for debugging.  I have never used Windows Forms.

[Steven_L_Intel1]

Do you use the VALUE attribute (Not !DEC$ ATTRIBUTES VALUE but the Fortran 2003 VALUE attribute) in interface blocks or dummy argument declarations? Older versions of Intel Fortran mistakenly treated this as pass-by-value (which it is only if the routine is also BIND(C)). We changed that behavior a couple of versions ago to match the standard, but your C interfaces may be using it incorrectly.

[gib]

Hi mecej4.  You are asking a lot.  The whole project is rather complex.  Before resorting to transferring everything, I'd like to see what clues come from the debug version, which I have just managed to build but not tested yet.  Regarding ITSOL, I don't see any version number.  I downloaded the source code in June this year, and I think it was the latest version then.  Initially I had to make a few changes to get it to compile, and I did employ iso_C_binding in a couple of places.  The whole thing is pretty messy.  I found the multi-platform option setting rather confusing (in protos.h), and the best that could be said is that it worked - or seemed to work.  As I mentioned, I have been running the program built with several VS versions, and I didn't mention that it also runs on a Linux cluster.  That persuaded me that my changes were OK.

Since the crash I am now getting is clearly ITSOL-related, I have been paying more attention to some of the compiler warning messages that I was no doubt wrong to ignore before.  These are warnings about BLAS and LAPACK subroutine names, "undefined; assuming extern returning int".  Thinking that these might be pointing to the cause of the crash, I have been fixing these by converting to the iso_C method of calling.  At this stage the multi-platform capability of protos.h has been wrecked, I think, since I have made a lot of changes thinking only about win32 operation.  None of these fixes have had any effect on the problem so far, but I have not finished yet.  There are three left, DGETRF, DGETRI, and DGESVD, all in svdinvc.c.  I will attend to these shortly.

By the way Jim suggested turning on stack trace.  How do I do this?

Thanks

Gib

[gib]

It was a very trivial error, but it look me a long time to track it down.  On each invocation of the solver I open a log file (linked to the particular instance, since I am using OpenMP to solve multiple problems simultaneously), and at the completion of the solution for one time step I close the log file.  (I'm solving a reaction-diffusion system with multiple constituents, the active number of which can change.)   I forgot to reset the FILE pointer to NULL.  Somehow this got past the earlier VS versions.  This kind of mistake is easy to track down in Fortran, which is one reason why I prefer coding in Fortran.