Showing results for 
Search instead for 
Did you mean: 

strange crash


We have a strange problem with a fortran DLL crashing within our application that we cannot identify. Of most concern is that a second recompile of the exact same code in the exact same environment has resolved the crash. We are using the Intel Fortran Compiler 15.0.0107.12 in Visual Studio 2013 Update 4 (12.0.31101.00).

In an include file we have:

structure /my_GUID/
  integer*4 data1
  integer*2 data2
  integer*2 data3
  character(8) data4
end structure
record /my_GUID/my_id

In a fortran file we have the following code:

my_id.data1 = 0
my_id.data2 = 0
my_id.data3 = 0
write(my_id.data4,'(8a1)') (char(0),i=1,8)

The 'write' call throws an access violation exception.

What could possibly cause inconsistent results from one compile to the next in our fortran code? Our QA team do not know what to expect with each release when we have stable code randomly causing crashes.

0 Kudos
6 Replies
Valued Contributor II

Hard  even start at a

Hard  even start at a diagnosis from the information we have. In my experience the most common causes of a problem going away on a rebuild is an out of date component in the previous build. When I make a final release I have a preference to always do a full clean build. It shouldn't happen in VS but it is a complex beast and it sometimes gets confused about what is up to date and what is not after you have made changes.

0 Kudos

Unfortunately we dont know

Unfortunately we dont know where to start with this, so not sure what other information to include that would be helpful.

We also always ensure each build is performed clean. Our continuous integration system deletes the build folder entirely, pulls source code and recompiles from command line parameters.

0 Kudos
Black Belt

I'd be differencing the

I'd be differencing the executable modules (as reported by a debugger) involved in a working run against those involved in a failing run , to try and understand where the variation is coming from.

0 Kudos

While the write statement may

While the write statement may be the location in the code where the error becomes noticed....

Some other section of code may have modified the code of the write statement itself (or any of the code it calls). The usual culprit of this is a hard to find write to an uninitialized variable or index out of bounds that then indirectly modifies a dummy argument reference up the call stack.

Have you performed a build with all the compile time warnings, and runtime checks?

Jim Dempsey

0 Kudos
New Contributor I

First off, did you upgrade

First off, did you upgrade the compiler recently because RECORD is deprecated from F77. You should use structures and % the data members. Sometimes, when Fortran developers start to add new things into a compiler they introduce bugs themselves. Have you tried to change just a small part of your code?



0 Kudos

RECORD was never standard

RECORD was never standard Fortran - that was a DEC extension.

Retired 12/31/2016
0 Kudos