| View previous topic :: View next topic |
| Author |
Message |
Wilfried Linder
Joined: 14 Nov 2007
Posts: 314
Location: D�sseldorf, Germany
|
 Posted: Thu Jun 24, 2010 3:39 pm Post subject: New storage model? |
 |
|
New storage model?
Today I�ve got an error and I�m looking for help. I use a module in which I declare a raster image:
| Quote: | MODULE M_VIEWIMA
...
CHARACTER, ALLOCATABLE :: CBILD(: )
...
END |
In some cases I use this variable meaning that I allocate it and initialise it with char(0). Now, when I call a subroutine, there is also the module from above included, so I don�t need to declare, allocate and initialise the variable again.
All this is running since years. In particular it works on a PC with Windows XP and FTN95 version 4.0.0. In between I use another PC with Windows 7 and the actual FTN95 version, and now my routines doesn�t work anymore: In the moment when within the subroutine I try to use the variable, the programme breaks down with an error message like �failed to write to location 000000FFF� or similar. Can anyone help me? I read something about a new storage model in FTN95 � may this be the reason?
Thanks in advance
Wilfried |
|
| Back to top |
|
 |
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
| Posted: Fri Jun 25, 2010 1:08 am Post subject: |
|
|
Wilfred,
To confirm the address you are attempting to use, I would compile with /debug to confirm the line number where it is failing, then either:-
1) print the array index then LOC(..) to file or second screen to see what is happening, or
2) compile with /check and use SDBG to watch the problem.
You did not indicate how often this routine is/has been called.
The problem you are having could possibly relate to some other previously called system service that is not working as expected with Windows 7.
Alternatively, I sometimes find it is an old mixed mode program error to be the cause. The new memory model may change the way local variables are ordered on the stack, changing what is being corrupted. This is all a guess.
I have used both memory storage models and not identified any problems like this in the past, although I only use XP.
John |
|
| Back to top |
|
|
Wilfried Linder
Joined: 14 Nov 2007
Posts: 314
Location: D�sseldorf, Germany
|
| Posted: Fri Jun 25, 2010 7:03 am Post subject: |
|
|
Thank you, John. I use the construction mentioned above in several subroutines within a big and complex software. With FTN95 4.0.0 and XP it works, with new FTN95 and 7 it failes in every case. I will try to isolate the problem as good as possible and then use /debug and /check as you wrote.
Regards, Wilfried |
|
| Back to top |
|
|
Wilfried Linder
Joined: 14 Nov 2007
Posts: 314
Location: D�sseldorf, Germany
|
| Posted: Fri Jun 25, 2010 9:42 am Post subject: |
|
|
| very funny... I just took few other variables out of the module and placed them directly into the subroutine and now it works... these few variables are only used in one single subroutine, so it was not necessary to include them in a module. No idea about what was going on, but everything is running, so the weekend can come. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
| Posted: Fri Jun 25, 2010 10:34 am Post subject: |
|
|
That does look like a corrupt stack... some where earlier in the program.
I'd be using IMPLICIT_NONE and checking for a mixed mode or array length errors (especially array(0) being defined).
/CHECK can find these, although if you use fortran 77 extensions, it may be a bit of a headache.
John |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
