- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am using a piece of code that uses CLOG (Complex Natural Logarithm) and it crashes inside CLOG. The message is
Unhandled exception at 0x77c5df76 in IX1Dv3.exe: 0xC0000005: Access violation writing location 0x00230ff0.
According to the pointer in the disassembly, it is trying to push a variable onto the stack when the error occurs.
The argument is an array element, I tried to circumvent the problem by declaring a complex (*8) variable in the subroutine and setting it equal to the array element in question and this does not help.
I am pretty sure that this code ran under the last version of Compaq Visual Fortran when I was using that (probably before 2010).
I am using Intel(R) Visual Fortran Composer XE 2011 Integration for Microsoft Visual Studio* 2010, 12.0.3470.2010, according to Help/About.
I am looking for suggestions. Any ideas?
Thanks in advance,
Charles
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm wondering if there is memory corruption somewhere else in the program. I can't imagine what would require CLOG to be storing into a non-stack memory location.
The first thing I would do is stop at the call to CLOG, switch to assembly view, and instruction-step-into. I still am skeptical that the error is actually in the CLOG intrinsic itself.
Another technique I would use is to comment out code after the CLOG call and see if the error still happens. I'd then start selectively commenting out code before it to see if that made any difference (understanding that the results would be wrong, but that's not important at this step.)
If the error persisted I would start disabling other code earlier in the program. This usually helped me identify what was going wrong. In my experience, the cause of errors like this were far removed from where the error became visible.
I wrote a small test that calls CLOG and stepped through it - I did not see any general memory writes.
If you can't solve this on your own, pack up a complete reproducing test case, including all sources, build files, data and instructions for running, and submit a ticket to Intel support.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Realistically, you need to provide sufficient source code to allow us to reproduce the issue before we can provide meaningful advice.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
INTEGER NL
REAL, ALLOCATABLE, DIMENSION (:) :: RHOL,D
END MODULE CSMTModel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the clog function is not given a type or an interface, you do not have implicit none so the return value is a default real not type complex.
This is further compounded by passing the return value as an arg also. Given the program is non-conforming who can tell what guesses the compiler makes and if those guesses are the same as some other compiler made in the past.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nope, CLOG is a standard specific name for LOG.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CLOG is an intrinsic function and the compiler should know exactly what type and number of arguments and also the return type, so I am not buying that argument. The argument is explicitly typed and this is also the return. Also the original code is commented out, also explicitly typed and that crashed as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Given that CLOG is a pure function, and thus doesn't write any storage, I am skeptical that it is actually CLOG that is the issue. You should run the program in the debugger and see where it really goes wrong. The traceback may be misleading.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
Nice to hear from you. You have responded to my questions before, mostly for CVF if I recall correctly.
I am running in the debugger. All is well until I call CLOG. then it breaks and I have to ask for disassembly to see anything. And that is not helpful to me, even though I have written code in PDP -11 Macro (assembly language) and IBM PC assembly language, but that was many years ago.
I am thinking there is some bug in the CLOG. I cannot right now find another explanation for this. The value going in to CLOG is valid (not zero, according to the spec in the documentation) and the argument is recognized by the debugger. Then the crash and error message, and disassembly is the only option and as I said, it is trying to push a variable onto the stack and there is an access violation.
Is there a work around? Problem occurs with both debug and release versions, with release of course there is minimal information.
Charles
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The code provided is incomplete - it cannot be compiled and run to demonstrate the problem.
It is easy to make unintentional errors with the use of fixed form source and implicit typing. There are other warning signs, - e.g. I think I see several cases of integer variables being used in contexts that require a logical.
I wouldn't be pointing the finger at CLOG yet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Charles, please attach the source code (in Zip or .tgz compressed format) to your reply, or provide a download link to a file in the Cloud. The code that you provided is in mixed format (neither fixed nor free), and posting it in line has possibly mangled the text further.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well you learn something every day, CLOG is an intrinsic! :-(
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm wondering if there is memory corruption somewhere else in the program. I can't imagine what would require CLOG to be storing into a non-stack memory location.
The first thing I would do is stop at the call to CLOG, switch to assembly view, and instruction-step-into. I still am skeptical that the error is actually in the CLOG intrinsic itself.
Another technique I would use is to comment out code after the CLOG call and see if the error still happens. I'd then start selectively commenting out code before it to see if that made any difference (understanding that the results would be wrong, but that's not important at this step.)
If the error persisted I would start disabling other code earlier in the program. This usually helped me identify what was going wrong. In my experience, the cause of errors like this were far removed from where the error became visible.
I wrote a small test that calls CLOG and stepped through it - I did not see any general memory writes.
If you can't solve this on your own, pack up a complete reproducing test case, including all sources, build files, data and instructions for running, and submit a ticket to Intel support.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve has the best idea so far. I did not write this code, it was given to me maybe 10 or so years ago and I did get it to work then, probably under CVF before I migrated to IVF since CVF does not run under Win 7. I did do some conversion to Fortran 90, replacing a common block with a module, for example.
I will first examine the code carefully for problems that might cause "memory leaks" and see if I can figure it out that way. If not, I will make a small project with just this code and see if that fixes it. If it does, the problem is somewhere else. This is a huge project but in my tests I am using a small portion of it.
BTW, I hate IMPLICIT NONE, FWIW. I have been writing FORTRAN and Fortran 90 code for nearly 50 years and have developed a style that suits me. For the first 25 years or so, IMPLICIT NONE did not exist in my world. Maybe the VAX had it, but I never worked on a VAX and did only minor work on a MicroVAX while in Cologne.
Thanks for all your comments. I will let you know what happens.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I went through and stepped through the code with a fine tooth comb. Now, it still crashes in debug mode, and one of the allocatable real arrays dimensioned (2) changes to a single unsigned character when CLOG is called. So something is really goofy and I cannot find it to date.
The release version seems to run OK, so I am good for now; this part of the code is rarely used and I probably have one prospective customer who wants it and no more.
I did fix the logical that was implicitly typed as integer (I have never known that to be a problem) and I found one variable that was typed differently in two different modules. One was a fairly complicated derived type (structure) and the second was an allocatable real*4 array. I fixed that by changing the name of the array and a number of other minor things, to no avail. Problems like this tend to arise when grabbing code from different authors...
I would have thought the compiler would have caught that. The clue was that it refused to allocate that "array" although it did not generate an error, which I thought was strange. I did manage to crash Visual Studio in the process of looking for the bug.
The code I posted does violate a number of things that I try to follow religiously, like omitting a decimal point so the compiler needs to recognize that I am not really comparing a real variable to an integer, but I doubt that that sort of thing will cause the crash. So I am still at a loss but it is working for now.
Thanks for all your comments and help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Stoyer, Charles wrote:....
......I would have thought the compiler would have caught that.
Based the old style code posted and implicit typing etc you must be using the compiler with many possible checks switched off which IMO is like using a circular saw without a guard, it cuts the wood just fine but you lose a finger now and then...... more checks == less bugs
anyway, glad you have made some progress....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Would it be a dumb question to ask if you've turned on runtime checking?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When I was a professor at Mines, I used to claim that there was no such thing as a dumb question!
Well, I am compiling and running in the debug mode, so I assume that is what you mean by turning on runtime checking? Most of the time this works really well, but this is one of those rare instances when the runtime error occurs inside of an intrinsic Fortran 90 function, where there is no source code to show the error and assembly language is the only code that can be displayed. I have written assembly both on the PDP-11 RT-11 systems as well as the PC in the DOS days, but it still does not tell me much to look at an assembly dump of intrinsic function code.
Even stepping through the Fortran code in the debugger shows very little. All I see is that an array is suddenly converted into a character variable!
But thanks for asking!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You have memory corruption going on somewhere, and I'd also guess that the stack is involved. As I wrote earlier, the actual culprit is likely to be well before the CLOG call.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That is for sure. We used to call it a "step on bug" where a call to a subroutine passes something different than the subroutine expects and the subroutine clobbers some data or worse. I haven't had time to successfully find the problem but the release version (without runtime checking) does not crash and I have only one (prospective) customer who need this so I am not really worried about urgently solving it right now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does debug mode turn on runtime checking? I never use debug mode. It seems to me that it might be useful to try runtime checking with the release version.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, I bit the bullet and spent about an hour and a half compiling the code after turning the Check Routine Interfaces back on. I have no idea how many lines of code there are in this software but there are a lot (2.67 Mb, plus a library, with little white space and not that many comments) and a lot of it came from FORTRAN 77 and the Ryan/McFarland compiler and later the Lahey Fortran. Most of the complaints addressed a harmless problem and even code that was not used in my previous test runs but there were one or two that looked not good. After correcting all of this so the compiler was happy, the thing does not crash in debug mode anymore.
Release version still works also. So that must have fixed it.
One way to break almost 50 years of Fortran programming evolution...
Assuming an average line length of 40 bytes, that is about 70,000 lines of code, not all of which is mine, originally.
Thanks for your help,
Charles
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page