Randomly Occurring Crash?

Hello,

I regularly recieve the following exception message: Additional Information: The runtime has encountered a fatal error. The address of the error was at 0x70b53757, on thread 0x864. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.

I usually recieve it after calling the same FORTRAN subroutine again after just having called it.

How can I prevent this crash from occurring and was it causing it?

Thanks, Alex.

0xc0000005 is an access violation and quite often means that a null pointer has been referenced. Presumably you are calling FTN95 that has been compiled with the /CLR flag?

I cannot see the /CLR flag in my compiler options for the FORTRAN project so I do not think I am compiling it with that flag, where is it set for the FORTRAN project?

If you are compiling for .NET then the IDE will add /CLR to the FTN95 command line. Both Plato and Visual Studio provide build logs that log the compiler command line that was applied by the IDE. To the user this is displayed as a .NET configuration (release, debug or checkmate) in a toolbar combo box.

Yeah I am compiling the fortran code to a .NET assembly which is called from a .NET WPF application. Is there anything I might be doing in fortran code that would cause these access violations?

To start with you should compile using checkmate and use the debugger to run to the point where the failure occurs.

Hey,

Sorry for the late reply but after using CheckMate to debug the FORTRAN I noticed the crash seemed to be occurring more consistantly, mainly on lines of code where virtual files were being written to. So I commented out these lines as they were not vital.

However I am still getting the same randomly occurring crash except more frequently now, and the main problem is that it tell me the source involved with the crash is not available so I think it is occurring in an external dll somewhere, possibly one of the silverfrost DLLs.

Also I am now getting this error message popping up after the crash: An unhandled exception of type 'System.ExecutionEngineException' occurred in mscorlib.dll

Im not sure if the above may have something to do with the failure of showing the source related to the crash.

So what else could be causing this? Also the code calling the fortran involves multiple threads, I noticed some compiler options relating to threading, however I am unsure as to what they do.

Thanks, Alex.

Two points:

1. Is the Fortran code standard conforming? If it is, try testing under Win32 rather than .NET. This might help identify the problem.

2. Can you identify the last call in the Fortran code that leads to the exception. If you can, are the arguments for the call valid?

Hey,

I have narrowed down this crash after spending more time on the FORTRAN module of my program. The FORTRAN seems to be randomly loosing pointers to .Net functions while waiting for the return value... So I think the reason it is occurring randomly is because the garbage collector is destroying what ever the FORTRAN is pointing to before the FORTRAN can get the result.

So does this sound about right? What could be causing this behaviour? How could I fix it?

Thanks, Alex.

If your Fortran points to a .NET object created in C# say, then DBK_LINK may not lock down the .NET object for you. In other words the garbage collector could mess things up for you.

You can use LOC in the Fortran to monitor the address whilst monitoring the same address in the C#. This will tell you if there is a problem here.

If there is a problem then you will need to lock down the pointer in the C# so that garbage collection does not kick in.

What is LOC?

LOC is an FTN95 intrinsic function that gives the address of the argument.

real x integer addr addr = LOC(x)

Here is a stackoverflow question I created on this issue because I can't figure out whether it is Silverfrost related or just a generic unmanaged code problem. There is more information on my issue in this question.

http://stackoverflow.com/questions/8321679/wpf-exception-being-thrown-after-execution-of-unmanaged-code