Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

strange crash

nick6
Beginner
455 Views

Hi,

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
COMMON /NEW_INPUT/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
andrew_4619
Honored Contributor II
455 Views

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
nick6
Beginner
455 Views

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
IanH
Honored Contributor II
455 Views

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
jimdempseyatthecove
Honored Contributor III
455 Views

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
Brooks_Van_Horn
New Contributor I
455 Views

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?

Brooks

 

0 Kudos
Steven_L_Intel1
Employee
455 Views

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

0 Kudos
Reply