Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

write(*,*) changes exe behaviour 1

Status
Not open for further replies.

GerritGroot

Technical User
Nov 3, 2006
291
ES
Hi,

I got an error that ehm... ...changes its location in the code.

The behaviour is different

EITHER

The program brakes down and windows says "yourexe.exe did something that's not allowed, send a report?"

OR

The program just stops, as if it ended somewhere in the middle and it returns to the blinking prompt.

The point is that if I place something like
Code:
WRITE(*,*)'I''m here now'
in order to find the error, the error occurs somewhere else in the code and if I place a new
Code:
WRITE(*,*)'But now we are here'
the program breaks down at some other location again.
If I do that until my whole code is loaded with "WRITE(*,*)" commands to detect where it goes wrong it runs normally. :-(

Is there a common cause for errors like these? I'm completely lost!

Thanks,

Gerrit

P.S.: I use gfortran
 
Maybe this helps...

I changed some write(*,*)'s and now got a window with a red cross in it saying something like:
Code:
Instruction 0x7c9469da refers to memory 0x00000000 which can't be read
...too much for a simple fortran programmer...

Hope ye get me some clue,

Gerrit
 
Could it have something to do with FLUSH after CLOSE?

Should I always flush before closing or doesn't that make any difference?

...maybe it helps if I panic first....
 
Have you tried to use the compiler options -fbounds-check and -Wall ?
 
-fbounds-check did the trick. Amazing how simple solutions can be sometimes.

In fact, the bounds where ok during the usage, only at initialising some array with -1, to make the debugging easier, one index too many was counted for.

Strange enough, the compiler accepted it, and the code ran perfectly for several iterations using the same array!

The error occured at arbitrary moments, even though the real coding error stood at the very start of the code, i.e. when initialising the array.

Luckily, I don't have to check my thousends of (DE)ALLOCATIONS now
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top