1 Topic by JohnWasilewski (edited by JohnWasilewski 2014-01-06 22:45:05)

Topic: 64-bit and 32-bit prob. solved

I've been using 64-bit for my project for a couple of months but, after converting to 32-bit, I'm getting good compilation but runtime memory conflict error/failure.   I have tried, and I believe I have managed, to copy into my 32 bit projects the exact equivalent settings to those I am using successfully in my 64-bit version.

The source files  are the very same files, in both versions.
Here's what happens.

64-bit
Compiles OK.
Runs OK

32-bit
Compiles OK
Runs, but fails as soon as I try to open a file with it.
When it runs, it brings up my splash screen perfectly well but, the very moment I pull down the file menu (in my program) to open a data file, it crashes.

This is the error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error: #0  ffffffff

One thing I've noticed (probably not relevant) is that the Compiler option to set the target CPU is a fixed setting which does not follow the project.   I have been compiling for my 32-bit library and executable using 'generic' and for the 64-bit lib and exec using 'amd64'. 

I strongly suspect that Jeff will be able to see straight away what I'm doing wrong, so I've sent him some relevant .prj files, makefiles and executables, plus a sample data file.  I'll report here if I learn anything new that might be helpful to others.
---
John

Re: 64-bit and 32-bit prob. solved

I have solved it. Very strange, nonetheless!

My main exécutable project had a statement,
UDat = DateToday()

It has this statement in the both the MAIN program, and then again in one subroutine
Both of these variables should be declared as CHARACTER*9

In the MAIN program, one of these two declarations is in a separately compiled MODULE. The other is declared explicitly at the start.  In the subroutine there was neither the necessary MODULE statement nor the necessary declaration.

This caused the 32 bit prog to die at runtime.   
What is hard to understand is why the 64 bit version, with the very same source files, didn't mind the error!

Jeff commented that It sounds like things shouldn't have even compiled if the subroutine didn't have UDat declared explicitly, although, if you don't declare it and don't include an "implicit none" statement, the compiler will assume it is a real.

My final thought: There must be something about how GFortran works, which enabled the 64-bit version somehow to find the same address for the same variables it had used before, when it entered my subroutine with the missing declarations.

Jeff advised me always to use explicit typing in future!
---
John