forums.silverfrost.com

PaulLaidler · Posted: Wed Mar 25, 2015 9:02 am Post subject:

Steve

If you are able to send me all of your code then I will aim to investigate the problem as time allows.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

Steve,

Your load map shows end as hex:03e2a000, which is decimal 65,183,744. This is about 62 megabytes, which is nowhere near the limit of memory use.
My thought of running out of memory does not apply.

My next approach would be to compile with /check and see what might happen. If the graphics does not work, you could try /debug and see if the stack dump identifies the problem.

Access violation suggests you are addressing outside you allowed memory. This can be either:
* you are addressing an array out of bounds, or
* the stack has been overwritten in some way; typically due to inconsistency between the subroutine call list and the subroutine expected arguments

An approach I have tried is to collect all the source code into a single file and compile with /check. It may show the argument list inconsistency.

There is a lot of scope for where this error could be !

John

dfwlms · Joined: 04 Jan 2005 Posts: 20 Location: Huntsville, Alabama

During the past week or so, I've struggled to get ZOOM working on Windows 8.1, making a few structural changes, increasing ZOOM's run priority, running in the safe mode, and using the debugger. Executables (Checkmate and Release) built on the Windows 7 machine run flawlessly on that machine and on a Windows XP machine. Executables built on a Windows 8.1 machine run flawlessly on a Windows 7 machine (probably on the XP machine too).

The error found by the debugger, after I'd operated the program for quite a while (clicking buttons), was almost surely a secondary result of the unknown primary error. The debugger thought that there were too many %bg commands. The code belies this, and if there was such a coding error, it would provoke a standard run-time system error (which never occurs). The failure is always manifested by the pop-up "ZOOM.exe has stopped working..." window, with no details provided.

The Windows 8.1 machine is the problem (new DELL with fourth-generation I3 single core processor). I've exhausted all approaches I can think of and am about willing to just reluctantly forget Windows 8.1.

The following download contains a synopsis of what I've tried, a listing of a routine that created the last window before one of the failures, and a screen shot of the failure. Any suggestions from those more capable than I (they are legion) will be appreciated.

The link is: http://trajectorysolution.com/Windows8-Problem.zip
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

David,

I too have experienced the problems you describe on my new Dell notebook which has Win 8.1 OS.
I would guess that the "ZOOM.exe has stopped working..." response you are seeing is because the program is waiting for something to happen. I get a similar message! It can be that the program is actually running and has not completed the calculation that is required to perform, but more likely it is waiting on some system response.
The frustrating think about these problems, is you start to blame all sorts of things you don't understand, such as incompatible "drivers" that need updating.
All we know is that something is not working the same as before and it is associated with moving to Win 8.1. The problem with using get_filtered_file@ (which started with Win 7!) is similar to this, but the solution is still elusive.

The problem can actually be a bug in our software, that has not been identified until now, although assuming a bug in Win 8.1 is more palatable.
Until we can identify where the program is waiting, we'll never know, so keep looking.

John

Steve · Joined: 23 Feb 2007 Posts: 73

John,
Thanks for your advice about compiling into a single file. I'll give it a go, but I do suspect an array out of bounds problem. A real misery, sorry, mystery !

Paul,
Thanks for the offer, but there is a rather lot of code !

LitusSaxonicum · Posted: Sat Mar 28, 2015 9:28 am Post subject:

Paul gave an answer in another thread that may help - a control variable has gone out of scope (in his case the control variable for %lw). When you move to a different version of Windows, MS compounds your difficulties by re-using released memory in different ways, so something that worked before only did so by happy coincidence.You can at least check for this by making everything as static as possible using SAVE.

This will completely mess you up if your code needs every last byte it can get its hands on!

In my experience, control variables and the like need to be in COMMON blocks that also lie in the main program with a SAVE, and this stops all manner of odd behaviours.

Eddie

dfwlms · Joined: 04 Jan 2005 Posts: 20 Location: Huntsville, Alabama

Eddie, Since first using FTN95 in about 2007, I've always "set global save" and "zeroize saved variables" in the project configuration setup. I believe that these were the default conditions for the FORTRAN programs I developed throughout the 60's and 70's (and maybe 80's and 90's also)... I'd never even heard of the SAVE statement until I retired in 2007. The programs I develop in retirement typically don't require much memory by today's standards. The comprehensive ZOOM trajectory optimization program (in-work upgrade) typically uses less than 10 MBytes of memory (earlier versions of the program used lots more because the dimensions of some arrays were much larger than needed).

The "ZOOM.exe has stopped working" failure still persists on Windows 8.1. Also, the latest version of Plato (personal version) has also been the victim of this failure a couple of times while running ZOOM.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

David,

The message "ZOOM.exe has stopped working" can be a bit misleading. What it could be saying is that it is not responding, but is busy working away and does not want to be disturbed; come back later !
I certainly have sympathy for this response.
Windows 8 has a few of these misleading messages!

John

DanRRight · Posted: Mon Mar 30, 2015 1:22 am Post subject:

Never had "Program stopped working " message to appear on the screen by itself without the obvious reason like array size violation by the running code or writing on screen (or screen and file, or screen and internal file) in two threads using Clearwin+ simultaneously when use fullmouseinput etc. Is this message after your actions trying to shuffle the frozen program with the right mouse in task bar?

PaulLaidler · Posted: Mon Mar 30, 2015 8:28 am Post subject:

This is not a definitive response but my impression so far...

If Windows 8/8.1 reports that a program has stopped working then it means that an exception has been raised. I suspect that this is over-riding the normal Silverfrost report.

If you are happy to edit the registry then run Regedit.exe and find the key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting"

Find or create the item "DontShowUI" and set its value to 1 (numeric one).

dfwlms · Joined: 04 Jan 2005 Posts: 20 Location: Huntsville, Alabama

Thanks for the suggestions everybody.

The "stopped working" condition has always occurred when a button is clicked. It's never occurred when the program is heavily-involved in calculating, such as calculating nominal and perturbed rocket trajectories.

It seems then that the problem is associated with some of the upgrades being incorporated.... those dealing with the displays of mission summary and rocket-stage summary information. These displays have been modified and now consist of a combination of %eb commands to display files that were just written, drawing commands to create a graphic of the rocket, and %^bt and %bt button commands.

The displays are created in this way so that the user can be reminded of the rocket configuration and can copy the displayed data into the keyboard buffer with the click of a button.

Before executing a %eb command, a previously written file is read, record by record, as a series of strings, which are accumulated into a single string for display. The end-of-record characters, char(13) and char(10), are appended to the end of each record, and the end-of-file character, char(0), is appended to the end of the single string. The %eb command displays the data so that it looks just like the file from which the information was read.

The length (an integer) of the resultant single string is input as an %eb argument. The HELP info says that a zero can be input and that the software will then figure out how much memory is needed for the string. But, this option hasn't worked for me.

This display method was used in earlier program versions for the display of lift, drag aerodynamic model files, and the earlier versions ran OK on a Windows 8.1 tablet (at least I never experienced a problem).

A difference with this upgrade is that the displayed windows also include a drawing of the rocket.

As I've mentioned before, using the button clicks to display the summary information can sometimes work properly for many clicks before the failure occurs on the Windows 8.1 machines (tablet and desktop). On the tablet, though, I don't get the "stopped running" window.... the program just disappears.

The program runs flawlessly with Checkmate on my Windows 7 machine (and on my Windows XP machine too, with an older version of Salflibc.dll). Even an executable created on the Windows 8.1 desktop runs flawlessly on the Windows 7 machine (at least no error has been experienced).

Paul, I will try your suggestion regarding the registry. However, given my lack of competence in dealing with the computer's inner workings, I may not be able to meaningfully interpret the results.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama

LitusSaxonicum · Posted: Mon Mar 30, 2015 4:31 pm Post subject:

David,

dfwlms · Joined: 04 Jan 2005 Posts: 20 Location: Huntsville, Alabama

Eddie,

I don't specify handles in the %gr commands. Two source files and screen shots of three ZOOM windows can be downloaded at:

http://trajectorysolution.com/zoom-info.zip

There are several subroutines and function routines in each file.

The Mission Synopsis window is produced by the examsel.f95 code, and the Mission Summary and Stage Summary windows are produced by the summaryOut.f95 code. The code in these files calls some subroutines that are not contained in these files, but maybe you can get an idea of how the graphics are being defined. If you need to see more, just let me know.

I appreciate you taking the time to take a look at this. Thanks.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama

LitusSaxonicum · Posted: Tue Mar 31, 2015 10:47 am Post subject:

David,

Thanks for pointing me to the code. My hunch was that you had a handle mixup between %gr areas, and at some point you were sending graphics commands to I know not where. You do have several %gr areas, however, and in my experience you do need to provide handles so that the right one can be selected with a call to SELECT_GRAPHICS_OBJECT@ and also on completion to UPDATE_GRAPHICS@. Certainly you need handles if you ever need to do hardcopy graphics, or revert to a %gr area created earlier.

You draw your rocket in a subroutine drawRocket that is within a sequence of WINIO@ commands, and just after the relevant %gr. I'm having a CRAFT moment her (Can't remember a flipping thing), but I do seem to remember getting in a mess with this years ago. The solution then was to put the graphics commands in a %sc callback to be drawn after the whole window is displayed. The documentation of %sc in the format code alphabetic reference includes the observation : "(for example, for drawing initial %gr data)" - so no doubt that is the right place to do it anyway.

You didn't include the drawRocket subroutine, but I would make sure it updated the graphics at the end of it.

As I write this, I'm beginning to remember that all sorts of other things ended up in my %sc callbacks that I originally did inline and had found that they created problems there, so this is my favoured answer. I understand that they are 'timing issues' and perhaps they are resolved on a faster computer? Just a guess.

My other observation was that sometimes you decide whether to extend or terminate a window with a WINIO@ containing little more than an &, and maybe it has something to do with that, but on the whole, I prefer the %gr/%sc approach as something I suggest you try.

Eddie

dfwlms · Joined: 04 Jan 2005 Posts: 20 Location: Huntsville, Alabama

It may have been more appropriate for this reply to be a private, but I couldn't succeed in sending it as a private message.

Eddie, Thanks much for your suggestions. The reason that my %gr commands are embedded in the winio statement sequences is that I don't know any other way to place the graphical surface at the desired place in the window. A good bit of trial and error was needed to get the placements I wanted. It seems that the %gr command should have positioning arguments (w.r.t. the window corner) as well as sizing arguments.

I did have a statement: jj =winio@(' ') to terminate a window, but I recently changed it so that a jj =winio@('...... %^bt', cb_buttonxxx) statement now terminates that window. That didn't solve the problem though.

I don't believe that it's possible to terminate a window with the continuation character, "&", in the winio statement. That would create an error from the get-go. In my code there may have been some non-winio statements following a winio statement with the "&" continuation, but eventually there would be more winio statements to complete the window.

I'll surely take a really serious look at the use of the %sc command. The decision I have to make is whether to do it before or after the upcoming upgrade is released. The program works flawlessly on the Windows 7 machine and on the Windows XP machine (with older salflibc.dll file). That fact is some evidence that there may be nothing "wrong" with the program. It doesn't seem likely that both Windows 7 (64-bit) and windows XP (32-bit) operating systems are tolerating bad code all the time (although that may indeed by the case).

The program usually requires less than 10 MB of memory when running (the requirement varies some with how the program is used... I noticed today that it was requiring about 12 MB while running on the XP machine). There should be no problem with insufficient memory (XP machine has 2.5 GB and windows 7 machine has 6 GB).

Again, thanks for your suggestions. I really appreciate them.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama