- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
RECORD was never standard Fortran - that was a DEC extension.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page