Bizarre behaviour - in part down to dual core cpu

You will know from my recent postings elsewhere in the forums that I am working on a callback to a %gr region. I have spent the past few days tearing my hair out with an intractable problem: made worse because I have been running the offending program on a dual core machine. In effect, the callback routine obtains the coordinates of a mouse click, and then decyphers them into real-world coordinates, effectively retracing the steps taken to scale the object onto the screen in the first instance. I generated a pair of double precision values stored in variables REAL_X and REAL_Y. These coordinates were handed to a number of subroutines to do various things with. Finally, they were handed to a routine that simply dropped them and substituted the values with what I presume is NaNs.

I checked all the obvious things - that REAL_X and REAL_Y were declared as double precision in caller and callee. I checked that the subprogram arguments were the same. I checked that REAL_* wasn't a name in once of the include files - although I never got to the bottom of whether I was getting tangled up with something to do with KIND in fortran-95, although I did replace the names with others just in case. Sometimes it would work, and sometimes it wouldn't - but I never got an error message, just an indeterminate wait.

I come from an older generation, and my idea of debugging is to put write statements in and see what is going on. I printed REAL_X and REAL_Y before entering the subroutine, and first thing inside it. Sometimes they transferred, other times they didn't.

Eventually, I came to the conclusion that there must be something wrong with my PC, so I tried the code out on my single-processor laptop. This time, I got an error message - to do with converting a double real to ascii, which I came to the conclusion was exactly what would happen if one attempted to print out a NaN. There's the same underlying problem, but at least the error was being reported.

Eventually, after trying everything I've ever thought of, I found a workaround. I simply passed REAL_X and REAL_Y via named common instead of as subroutine parameters.

The point of this ramble is:

1. There is something deep and dark about subprogram parameters in FTN95 v4.9.0 that has defeated me, but which is fixed by communicating via COMMON, and,

2. If you get some types of problem on a multi-core cpu machine, you don't see the error message.

I guess that 2. is caused by Windows XP doing multi-threading, but as for No. 1 - I still don't have the first idea how two double precision values can be passed OK sometimes, and not others.

Regards

Eddie B

I assume that you are taking the usual precautions of using IMPLICIT NONE and testing under /CHECKMATE.

Hi Paul,

IMPLICIT NONE doesn't help - because nothing is given any type when declared in a COMMON block, so to have moved from sending REAL_X and REAL_Y as parameters, i.e. through

CALL SUBROUTINE XYZ (REAL_X, REAL_Y)

to instead

COMMON/GEOM_XY/ REAL_X, REAL_Y

shouldn't change their type - either in the caller or the callee. Getting the error message (eventually) confirmed that the callee considered them double precision, and they had already been successfully passed to other routines.

The problem arose on both single and dual core cpus, but is so difficult to recreate, that it probably will never be heard of again!

In any case, I'm not a big fan of IMPLICIT NONE. I never know the type of anything - which is why I find other folks' code too dificult to read, and it defeats the original intention of Backus.

Clearly, I will have to explore CHECKMATE.

My dual-core machine also sometimes blanks the screen for a second when running this particular application, but this definitely doesn't happen - ever - on a single core cpu. So, allied to the problem that some types of error message may not appear on a dual core machine suggests that here is a problem you may hear about from elsewhere in due course.

Regards

Eddie