forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Access Violation When Running with Windows 8.1 Operating Sys
Goto page 1, 2, 3, 4  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
dfwlms



Joined: 04 Jan 2005
Posts: 19
Location: Huntsville, Alabama

PostPosted: Mon Mar 09, 2015 8:23 pm    Post subject: Access Violation When Running with Windows 8.1 Operating Sys Reply with quote

A trajectory optimization program I've been developing/enhancing over an 7-year period is now having some run-time access violations when running with Windows 8.1. The program is being developed on a Windows 7 Machine and has no issues on that machine or on a Windows XP machine (at least not yet observed). Previous versions of the program also had no issues running with Windows 8.1.

The program has a comprehensive GUI, generated with the various winio@ commands. It appears that the access violations may be related to the use of the %eb command (to generate various edit boxes), but this is really just a guess.

Version 5.5.0.0 of FTN95 is being used along with Version 12.2.27.20. of Salflibc.dll.

Any help are suggestions are welcome.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6851
Location: Salford, UK

PostPosted: Mon Mar 09, 2015 8:40 pm    Post subject: Reply with quote

Have you tried compiling using /DEBUG and running the program from the debugger SDBG?

After that you could try downloading the latest personal edition of FTN95 to see if it is an issue that has been resolved. If you can do this on a different machine then it avoids any problems that might arise through having two versions on one machine.
Back to top
View user's profile Send private message AIM Address
dfwlms



Joined: 04 Jan 2005
Posts: 19
Location: Huntsville, Alabama

PostPosted: Mon Mar 09, 2015 10:08 pm    Post subject: Reply with quote

Thanks Paul. Although I've developed many Fortran computer programs since 1963, I've never used a debugger. In the early years, we had to be really careful (slow turnaround), and I didn't make enough mistakes to require learning how to use the debugger. I normally track down bugs using print statements and trial-and-error. That usually works well. In a case like this though, when there is a run-time system error, all I can do is look at the code and see if anything may go out of bounds. I don't really know how to interpret the access violation data that is displayed.

Incidentally, the Checkmate compile option has never worked for me. I can't even get the compiled program executing when I compile with that option, even though the program, compiled with the Release option, has run flawlessly in many upgraded program versions on several Windows operating systems. When running on windows XP, I do have to use an older version of salflibc.dll than I do when running on Windows 7 and Windows 8.1.

Thanks again for your suggestion. I really appreciate it. This old dog may have to learn a new trick to find the problem this time. I will download the personal FTN95 version and try to keep it separated from what I have now, just to see if it solves the problem.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6851
Location: Salford, UK

PostPosted: Mon Mar 09, 2015 11:49 pm    Post subject: Reply with quote

In general it is not safe to use versions of FTN95.exe and salflibc.dll that were not released together. We try to make them interchangeable but it can cause problems.

It is a good idea to try some simple programs, stepping into the debugger.
You will find it quite easy and a very powerful tool.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2273
Location: Sydney

PostPosted: Tue Mar 10, 2015 12:58 am    Post subject: Reply with quote

David,

Even if you do not use SDBG, I'd recommend you try compiling with /check or /debug.

/debug does put the routine name information into the .exe, so if the program does crash, you get a stack dump with the call list and line numbers of where the crash occurred. This does not have a big affect on performance.

/check is more extensive. It will give you a subroutine argument check for the routines you have written, but not necessarily for the library routines you call. It also checks for array subscript bounds, than can cause problems. There is a performance penalty, but still runs much faster that the optimised code you compiled 20 years ago.

If you place all your code into 1 .f95 file, /check will check the subroutine call lists at compile time, plus also check the consistency of library calls. You never know what it might show, although Fortran of 60's and 70's did encourage mixed mode arguments for memory management.
There are other new Fortran changes, such as static > dynamic storage and initialisation of variables.
I have seen a big improvement in robustness by adopting ALLOCATE for arrays, rather than the old memory management.
FTN95 is also severe on temporary arrays and stack overflows. Moving large arrays to COMMON or modules helps, as does using ALLOCATE for temporary arrays that would otherwise go on the stack. You probably know about these, as they were a bigger problem in 60's and 70's.

Do you generate a load map from slink ? Could you be using a lot of memory. This can also start to generate some unusual errors with changes to O/S.

I hope these comments might help, although the problem may be as simple as incompatible salflibs.dll for the .exe you generated.

John
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2286
Location: South Pole, Antarctica

PostPosted: Tue Mar 10, 2015 2:06 am    Post subject: Reply with quote

Dfwlms, Checkmate (which is the same as /undef) is one of the largest achievement of this compiler starting from the era of FTN77. Copycating it, others also slowly started introducing this ultimate deep cleaning option into their gear decades later. If your code is larger then 20K lines i'll bet $20 that you have so many small and possibly large bugs Checkmate will discover that you will be amazed and ashamed. I can claim that any large program which never compiled with Checkmate is a holly mess and bugotron. And 200K lines programs without Checkmate are just plain wrong. Such codes die naturally under the weight of own hidden bugs. I'd cut programmer's salary 5% for not using it at least ones in a while.
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Sat Mar 14, 2015 8:31 pm    Post subject: Reply with quote

Following this thread, John, you suggest using large / many arrays could produce unusual errors.

My many, some large arrays, are now all static in COMMON. When running in Windows Vista I experience no problems. Running now in W8.1 I am able to generate a crash quite readily.

I have never used SDBG - writing my own tracing within the code has more than proved adequate - however, I am now baffled. Compiling all my source with either /CHECK or /UNDEF I can still crash the app but once I invoke SDBG I cannot force a crash.

What can SDBG be possibly shielding ? surely I must not be left to run my app via SDBG from now on ?

This app is currently compiled with the Personal Edition and SDBG from the same installation.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2273
Location: Sydney

PostPosted: Sat Mar 14, 2015 11:37 pm    Post subject: Reply with quote

Steve,

I don't have any explanation for your problem.
I don't use Win 8.1 very often, as it is on my notebook and I find my Win 7 desktop more useable.
My approach would probably be similar to yours.
I would check the load map and see how much memory you are using. Are you near the limit?
I would definitely compile with /debug as this gives the line number where the crash occurs.
If you transfer some arrays from COMMON to being allocatable in a MODULE, you possibly could reduce the memory usage if they are not all used at the same time.
If the problem is not memory related, assuming you have slightly less memory available with Win 8.1 then I don't have many ideas. See other posts, as Get_filtered_file@ can cause this problem.
It could be a long standing bug that has never caused a problem before, such as an un-initialised array subscript that was previously zero and is now something else. ( /undef could show this )
If you are already using /check or /undef, doesn't it show where the problem is being recognised?
I don't know your program to know how reproducible the problem is, but there is going to be a reason for the crash.

Good luck,

John
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1490

PostPosted: Sun Mar 15, 2015 3:32 pm    Post subject: Reply with quote

Steve, it does not follow that when you use /debug to compile and link you must run the program under SDBG. Using /debug does two things:
    1. Puts debug symbols into the OBJ and EXE files
    2. Adds code to print out a traceback after a fault, so that you know the line number and the routine name within which the fault occurred, and the chain of calls that resulted in control reaching that line.


The unpredictability of the occurrence of the error is an indication of a memory access error of some sort -- array bounds exceeded, uninitialized array index being used, etc.

David Williams wrote:
Quote:
Incidentally, the Checkmate compile option has never worked for me.
Does your program used precompiled static libraries? If so, you cannot use the /checkmate option without doing some more preparation. If you convert the static libraries into an equivalent DLL (or set of DLLs), /checkmate can be used in the code that calls routines in those DLLs.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1509
Location: Aerospace Valley

PostPosted: Sun Mar 15, 2015 9:42 pm    Post subject: Reply with quote

... back to the original problem, David, you said:
"Previous versions of the program also had no issues running with Windows 8.1. "

How long ago is it since this win 8 problem arose ?
What changes have you made since then?
These are the initial questions you have to ask yourself I think to try t pinpoint the error.

As for the unintelligible (if I've interpreted correctly) messages ... welcome to the club, just gives weight to my post of just yesterday in 'Suggestions' ! Wink

Maybe posting the actual Access violation message stuff might help someone who knows a little to narrow down the possibilities too.
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Tue Mar 17, 2015 2:08 am    Post subject: Reply with quote

Thanks John - I need to search further.

Thanks mecej4 - I've not used /debug before, I'll give it a go.
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Mon Mar 23, 2015 6:00 am    Post subject: Reply with quote

Paul,
I have tried all compiler options as far as I know, and still my code crashes in W8.1 - and with no traceback - but not in Vista.
Placing a single WRITE(*,*) statement or even to an external file, however, does not crash.
If there is a memory allocation problem, what clues should I be looking for in the .map, please ? If there are indeed problems with allocation, are there SLINK options I can apply to overcome them ?
Thanks, as ever
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2286
Location: South Pole, Antarctica

PostPosted: Mon Mar 23, 2015 10:01 am    Post subject: Reply with quote

Some crashes are very hard to fix. I have one for last couple years in large multitab %ps. All suggestions failed. Worst of all the crash disappears when the code is under SDBG. Spent few days, localized the place, but to make small demo have no more spare time to spend for Paul to fix that, may be later, thing is not that critical. Not sure it is 8.1 OS thing. This could also be my own mistake.

As one more suggestion, if all is simple, no mixed language programming and libraries etc, and you do not worry to put the whole code in open access, you can post it together with instructions how to run it into crash and people who have spare hour or two may fix it. I'd personally pay 50 bucks if someone fix my damn annoying @#$$% but unfortunately i can not post it Sad


Last edited by DanRRight on Mon Mar 23, 2015 10:39 am; edited 1 time in total
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2273
Location: Sydney

PostPosted: Mon Mar 23, 2015 10:30 am    Post subject: Reply with quote

Mecej4 wrote:
Quote:
Does your program used precompiled static libraries? If so, you cannot use the /checkmate option without doing some more preparation.

I am not sure that this is the case. If you use libraries that were not compiled with /debug or /check ( ie as default or /opt) I would expect that the routines in these would not be visable to SDBG and treated as a black box. I would still expect SDBG to skip through them, although I can't recall actually testing this.

John
Back to top
View user's profile Send private message
dfwlms



Joined: 04 Jan 2005
Posts: 19
Location: Huntsville, Alabama

PostPosted: Tue Mar 24, 2015 2:53 pm    Post subject: Program Stops Working on Windows 8.1 Desktop Reply with quote

Thanks to all who have helped with suggestions. I will try to make use of as many as is practicable.

The changes made to the program,since the latest-released version (7.3) appeared to work OK on a Windows 8.1 tablet, have included no new kinds of functions as far as I can tell. The in-work program executable is about one-sixth the size of earlier versions and requires about 1/20 as much CPU to run. One reason for this is that contextual-help windows used to display image files (resources), and now they display plain text files (from a folder). Also, some arrays had excessively large dimensions, and these dimensions have now been greatly reduced.

The %eb command is used more in the in-work version because that is how the contextual-help text files are now displayed, but %eb is also used in earlier versions to display other text files (also in folders) containing aerodynamic model data.

The program executable files that are produced from compilations using Checkmate get the same kind of result as those produced from compilations using the "Release" option. As I've said before, the "... has stopped working" problem appears to occur at a random time/situation when some GUI button is clicked. There may be some specific command or sequence of commands that cause the problem, but I've not yet been able to identify it/them.

At this point, it appears that the in-work version is just not completely compatible with Windows 8.1 somehow. It is a 32-bit program, but that shouldn't be a problem. And, typically, one can get a lot of work done with the program on Windows 8.1 before the program stops working. Sometimes though the program stops working before much can get done.

Is it likely that some background process is interfering with the program?

There have been many upgrades of the program over several years, and it has always worked flawlessly on Windows 7 and Windows XP (SP3) machines. The in-work version, being developed on the Windows 7 machine with older PLATO and salflibc.dll files, works flawlessly on the Windows 7 machine, and I think also on the XP machine (not tested it extensively on XP yet). Also, the in-work version developed on a Windows 8.1 machine with the latest PLATO and salflibc.dll programs appears to work flawlessly on the Windows 7 machine, but it too fails on the Windows 8.1 machine in the same way.

The "crashes" on the Windows 8.1 machine do not produce a systems-error type window. What appears is the nice little ".... program has stopped working" window, with no details about the problem. And Windows 8.1 does not close the program automatically, even though the program is dead.

Anyone who's interested can download a free copy of the most-recent released version of the program (ZOOM) from the webpage: http://trajectorysolution.com/ZOOM%20Program.html

Thanks again for all of your suggestions.

David Williams
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group