On Dec 13, 2007, at 12:42 PM, Rich Cook wrote:
That's not my obvious thought! :-) That kind of "this can't be
real" behavior makes me think that maybe you have some sort of
linking issue -- are there several objects getting linked together?
Can you do a "make clean" and rebuild and does that help?
There is a step where a bunch of object files are put into an
archive for linking, but I always remove all of the object files and
archive file before doing a rebuild.
Another "obvious" thought to me is that perhapss you have a buffer
overflow error in a stack or heap variable.
Similar to what Eddie posted, I tried compiling an executable with
all checking turned on ( -C ) and when I do this and compile the
code,
the executable runs to completion without any problems.
If you leave the write statement out, I forget, what happens? Your
program crashes? Where does it crash? What call is being made?
The program crashes with a:
forrtl: severe (174): SIGSEGV, segmentation fault occurred
And in gdb it tells me where:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000014d7fffff
0x00000001001fc8cd in for__get_s ()
(gdb) backtrace
#0 0x00000001001fc8cd in for__get_s ()
#1 0x000000010021337b in for_read_seq_fmt ()
#2 0x0000000100148b27 in getprm () at getprm.f:108
#3 0x0000000100146851 in field () at field.f:57
#4 0x000000010019f6fb in mechanic () at mechanic.f:54
#5 0x0000000100001467 in analyze () at analyze.f:50
#6 0x00000001000013e4 in main ()
The last two function calls originate from the Intel libraries
itself.
The same code builds and run as a 32-bit executable. Everything I
try to do to see if the problem is originating in the code causes the
problem to go away. But I don't want to say it's a compiler bug until
I show more conclusively that something stupid in the code is causing
this.
The same code also compiles and runs fine (as a 32-bit or 64-bit
executable) with gfortran and the Portland Compilers on Mac OS X.
I'm simply at a loss as to what to try next.
Thanks to everyone for their help so far.
Dave
David W. Gohara, Ph.D.
Center for Computational Biology
Washington University School of Medicine
http://gohara.wustl.edu
http://www.macresearch.org
314-362-1583 (phone)
617-216-8616 (cell)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Scitech mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden