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 Previous  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
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Tue Mar 31, 2015 10:47 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
dfwlms



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

PostPosted: Tue Mar 31, 2015 11:26 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Apr 01, 2015 9:45 am    Post subject: Reply with quote

David,

I think my PM folder may be full. Sorry.

The %gr and its size information must go in one of the sequence of WINIO@ statements: there isn't anywhere else to do it. Apologies if you were misled by the way I put it.

The problem is (I think) that you are drawing your rocket by calling the drawRocket subroutine before the window is fully created (i.e. in the middle of a bunch of calls to WINIO@). %sc gives you a chance, via its callback, to call drawRocket after the whole window has been created, including the embedded %gr area.

My hunch is that Clearwin+ hasn't finished setting up the graphics area and all its internals before you want to draw to it. Hence, instead of:

Code:
JJ=WINIO@('%gr ...
CALL drawRocket(...
JJ=WINIO@('% ...


have

Code:
JJ=WINIO@('%sc&', CALLBACK_TO_DRAWROCKET)
JJ=WINIO@('%gr ...


in which

Code:
INTEGER FUNCTION CALLBACK_TO_DRAWROCKET ()
...
CALL drawRocket(...


I think that it is probably a mistake to assume as your code does that the %gr area is ready to accept graphics commands immediately after it has been specified. You can't put drawRocket after the last WINIO@ because that statement won't be executed until after the window closes! However, the callback to %sc executes when the window is complete.

You can position %gr using %nl, %ff, %ta, %ap and %rp format codes (and probably some others too) and since they apply to every control, they make Clearwin+ simpler for Paul in comparison to have positioning info for each control! %ap is absolute positioning. The coordinate units are average character size cells, not pixels, but that is how Windows works.

To clarify other points:

1. Having thought some more, I don't think it is in how you finish a window that is causing the problem.
2. You need a handle to %gr if you have multiple active %gr areas and want to move between them. (you don't do this)
3. You need a callback to %gr if you want to accept graphical input or update the image in a serious way. (you don't do this)

But, you must do a graphics update (CALL PERFORM_GRAPHICS_UPDATE@( )) at the end of the drawing commands.

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



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

PostPosted: Wed Apr 01, 2015 8:49 pm    Post subject: Reply with quote

Eddie, I just created a simple example combination of text and graphics using the %sc command with its call-back function. It took me a while to realize that the call-back function had to be set to a positive number (e.g., cb_callback = 1) inside the call-back routine for the program to pause and display the result of the last winio statement in the calling routine. Otherwise the last winio statement would be skipped and the displayed window would appear for only a small fraction of a second.

Now I'll begin to apply the %sc approach to the ZOOM program, a bit at a time. Thanks for your help.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Thu Apr 02, 2015 11:43 am    Post subject: Reply with quote

David, Here are couple thoughts on sources of crashes and their cures

1) temporal cure: try set compatibility of your zoom.exe file by clicking on it with right mouse and make the file compatible with Windows 7 in dialog Properties/Compatibilities/ etc. That may work or not.

2) another temporal cure which just decreases probability of crash: make sure all variables are real*8 since Windows 8 does not like exceptions specifically caused by underflows. But better not to allow underflows at all

3) One of common sources of Clearwin+ crashes is when you click again the same button but some stuff inside callbacks is not completed making two conflicting threads

To avoid that you may need to introduce global integer flag, say, ifProgramIsRunning, set it initially to 0 and when inside callback the first statement has to be a check if it is 0 or 1.

If it is =0 set it =1 and run the source of callback, if it is 1 then go straight to the end of callback function to avoid callback to run. At the last statement of callback main source flow before last statement callback=2 (whatever callback name is) make ifProgramIsRunning=0 again - that is the sign that will allow callback to work next time.

Now if you click the button by mistake twice before everything is finished the callback will not be executed and there will be no crash

4) avoid writes (both to media and internal writes) in simultaneous threads launched by keyboard, mouse click or full_mouse_input movement. Way to handle that - see #3 above. In more complex cases when write to disk and on screen simultaneously is unavoidable i used my own integer-to-character and FP-to-character functions for direct transformations which do not use internal writes.


Last edited by DanRRight on Thu Apr 02, 2015 5:42 pm; edited 1 time in total
Back to top
View user's profile Send private message
dfwlms



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

PostPosted: Thu Apr 02, 2015 5:17 pm    Post subject: Reply with quote

Eddie and Dan,

There are 16 places in the code where the rocket-drawing routine was being called from the midst of a block of winio statements. In these places, I substituted %sc commands and called the rocket-drawing routine from the associated callback function (actually, there are three callback functions to support three different arguments in the call to the rocket-drawing routine).

There are three other calls to the rocket-drawing routine that are made as the program iterates to find a solution (these calls are not embedded in a block of winio statements). So, as the program iterates you can see the rocket configuration changing. When this part of the program is executing, the "stopped working" error has never occurred. I couldn't use the %sc approach for these three calls (or, more correctly, I didn't know how to do it).

The modified program worked just as before with Windows 7 and 8.1. Unfortunately, the "ZOOM.exe has stopped working" error still occurs with Windows 8.1, although sometimes lots of button clicks (work accomplished) can be done before the error occurs. The error eventually occurs even if I choose the Windows 7 compatibility option while running on Windows 8.1.

In the project properties (in the Plato IDE), I always set the real-number kind to 2 and the integer kind to 3. And I always use the "global save" and the "zeroize saved variables" options. The way the program is structured, I don't think it's possible to click a button before a callback function has finished executing.

I noticed something by running Task Manager while executing ZOOM on both the Windows 7 and Windows 8.1 machines. On Windows 7, clicking a ZOOM GUI button has no effect on the memory or CPU requirement of Windows Explorer. But, on Windows 8.1, every time a ZOOM GUI button is clicked the memory and CPU requirements for Windows Explorer change (in fact, the changes appear to be in sync with changes in the ZOOM requirements). The changes in the Windows Explorer requirements have a response time.... sort of like a first-order lag. It takes the displayed memory and CPU requirements of Windows Explorer two or three seconds to stabilize after a ZOOM GUI button is clicked. Is it likely that there is some kind of conflict between ZOOM and Windows Explorer?

I believe that all of the write statements in the program code are writes to "external" units. Even the code to convert an integer into a string is done by writing to a unit using integer format, rewinding the unit, and reading the unit using a string format (these type conversions should probably have been done with internal writes... more elegant).

Thanks to both of you for your suggestions. There are still some that I've not tried, but will try them if I have the time.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Apr 03, 2015 5:32 pm    Post subject: Reply with quote

David,

Well at least some progress is being made!

Are you sure that you have moved all the drawing surface subroutine calls (where relevant) into the callback to %sc?

It looks to me that you may still be writing to a %gr window before it is created using SIZE_IN_PIXELS@ or some such as this is the font size command sent to a %gr area. My understanding is that this works in the currently active drawing surface, and doesn't set up a default if there isn't a fully-formed drawing surface yet.

Once the drawing surface is formed, there is no reason why graphics commands shouldn't be issued to it as and when you wish to update it, but you do need a graphics update at the end of each phase of drawing. Having a handle, and selecting the graphics object each time, does allow you to test if it is still accessible (via the return code).

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



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

PostPosted: Fri Apr 03, 2015 6:16 pm    Post subject: Reply with quote

Eddie,

Before the program begins its iterations to fine a quasi-optimum solution, it creates a drawing surface with %gr. Then during the iterative process, direct calls to the draw-rocket routine are made. The argument in the call to the draw-rocket routine causes the routine to first draw a filled rectangle on the drawing surface to blot out the previous drawing. As the program iterates, you can observe, in the general case, the dimensions of the rocket stages changing, etc.

The "....has stopped working" failure has never occurred during the iterative process, where the draw-rocket routine is often called many times. The error has always occured when looking at a synopsis of the result. This can be done without any iterative procedure. A mission can be selected from a list and then summary data, plots, and other information can be looked at. As best I can remember, the failures always occur when examining a mission's synopsis (usually the summary data). These examinations are done often, so it is possible that the stop-working failure could occur at other places... such as where one is defining all the properties of the rocket stages before attempting to obtain a solution, as these places are not as often exercised.

There appears to be no difference in failure results with and without the %sc approach.

I did replace a much-used block of logic (that used write, rewind, read, rewind sequences to an external file to convert integers to strings for use in output formats) with internal write statements. I then executed the program for a long while on windows 8.1, and was getting optimistic, before the dreaded "stopped-working" error happened.

I might add, that beforehand I had discovered an underflow problem (the check-underflow option was selected when building the program). This problem was corrected. Of course, there may be other underflow situations not yet discovered.

My intuition (maybe not very fallible) is that there is some background process in Windows 8.1 that is involved with the "stopped working" failure.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama
Back to top
View user's profile Send private message
dfwlms



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

PostPosted: Fri Apr 03, 2015 8:02 pm    Post subject: Reply with quote

Eddie,

I failed to address your suggestions directly in my previous reply. I used the %sc command for the drawing surfaces where the rocket configuration would be drawn (there were the three exceptions I mentioned earlier, where the rocket is drawn repeatedly to the same surface during the program's iterative procedure). The drawing of the rocket in some new places, with differently formatted windows, is a salient feature of the in-work upgrade. As far as I've been able to determine, the previous versions of ZOOM have worked properly with Windows 8.1, and so I was especially suspicious of these new drawings of the rocket in the in-work program version. Also, some of these new drawings are on drawing surfaces that are in windows where the text is produced with the %eb command... a combination not in earlier program versions.

There are other %gr commands in the program where other things are drawn, such as plots, etc., where I did not use the %sc command. These sections of the code have not been materially changed in the upgrade modifications, and restructuring the program to use the %sc command in these places could be a pretty big job.

Thank you for your suggestions regarding the drawing-surface handles so as to allow a better diagnosis. As time permits I'll try to incorporate these.

If memory serves, every time the ".."has stopped working" error occurs, a button has just been clicked to display a new window. And, I think that the new window is always completely displayed (with the small stopped-working error window in front of it). And, it may be true that all of these windows have a drawing of the rocket in them.... I'm not certain.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama
Back to top
View user's profile Send private message
jalih



Joined: 30 Jul 2012
Posts: 196

PostPosted: Sat Apr 04, 2015 9:20 am    Post subject: Reply with quote

Hi dfwlms,

Have you considered about calling TEMPORARY_YIELD@() somewhere between all the heavy calculations and drawing code or better yet, put calculations and drawing code inside a separate thread?

That way, you would not block message queue for the duration of the calculations and your application would always keep responsive plus you could get rid of the "Do Not Disturb Window or Click Mouse Button Until Process is Complete" messages in your program.

The easiest way to add worker thread for the application would be to use the Thread Pool API.

I have written a simple wrapper DLL for the Thread Pool API. It currently has following functionality:
Code:

  ! Thread pool wrapper functions in tp.dll
  STDCALL TPEnvNew 'TPEnvNew' ():INTEGER*4
  STDCALL TPEnvDelete 'TPEnvDelete' (VAL)
  STDCALL TPCreate 'TPCreate' ():INTEGER*4
  STDCALL TPSet 'TPSet' (VAL, VAL)
  STDCALL TPClose 'TPClose' (VAL)
  STDCALL TPCreateWork 'TPCreateWork' (VAL, REF, VAL):INTEGER*4
  STDCALL TPCloseWork 'TPCloseWork' (VAL)
  STDCALL TPSubmitwork 'TPSubmitwork' (VAL)
  STDCALL TPCreateCleanupGroup 'TPCreateCleanupGroup' ():INTEGER*4
  STDCALL TPCloseCleanupGroup 'TPCloseCleanupGroup' (VAL)
  STDCALL TPSetCleanupGroup 'TPSetCleanupGroup' (VAL, VAL, VAL)
  STDCALL TPCloseCleanupGroupMembers 'TPCloseCleanupGroupMembers' (VAL, VAL, VAL)
  STDCALL TPWaitForWorkCallbacks 'TPWaitForWorkCallbacks' (VAL, VAL)
  STDCALL TPSetThreadMax 'TPSetThreadMax' (VAL, VAL)
  STDCALL TPSetThreadMin 'TPSetThreadMin' (VAL, VAL)



Let me know, if you are interested and I will put the DLL with some example ClearWin+ programs available.
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Sun Apr 05, 2015 6:04 am    Post subject: Reply with quote

I can't help think that we're losing track of the fact that David's program works fine on Win7 / Win XP but NOT on Win8.
I have difficulty in imagining it has anything to do with the code itself for that reason.
Googling, there seems to be quite a lot of problems with Win8/8.1 in similar respects, just not tracked down one sufficiently similar to confirm that.

Whilst all the suggestions above are certainly valid ones to improve the program I can't help think we're not progressing in the direction of the root cause.
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Sun Apr 05, 2015 11:36 am    Post subject: Reply with quote

having read through the post again, I saw you wrote just above:

Quote:
the previous versions of ZOOM have worked properly with Windows 8.1


I assume by that you mean that the already compiled (on Win7 or WinXP program works when executed on Win8 machine?

Now, have you tried compiling an old version on a Win 8.1 machine and then seeing if that executable runs OK ?

If it does work OK, then logically the problem is related to the code changes, if not then the problem is 100% Win8.1 problem of some kind ..... I think !
Back to top
View user's profile Send private message
dfwlms



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

PostPosted: Sun Apr 05, 2015 11:14 pm    Post subject: Reply with quote

Thanks to all for the help you've offered in trying to find the cause of the "stopped working" failures of ZOOM on a Windows 8.1 machine. I haven't yet responded to some queries and comments, but I appreciate them all and will keep them in mind. I might mention that I'm not much of a computer programmer, although I've done lots of it (only FORTRAN). For example, I don't really know what's meant by a "thread".

Today, for the first time, a previously-released version (7.3) of ZOOM "stopped working" while being exercised. It happened on a Windows 8.1 desktop, and it DID NOT involve a drawing surface. I also experienced the same kind of error today with the in-work upgrade version of the program. These "stopped working" errors occurred while scrolling vertically in an edit-box window (%eb) which contained a lot of data..... time histories of quite a few state variables. Today was the first time I remember encountering the "stopped working" error in a window with no drawing surface.

So, it can now be said that the upgrade modifications are not responsible (at least not solely responsible) for these "stopped working" errors. And, the cause(s) may not be related to drawing surfaces. Also, it is likely that the errors will not occur on Windows XP and Windows 7 machines, where ZOOM has been exercised a lot. It is likely that there is a ZOOM / Windows 8.1 incompatibility problem of some sort. In one instance, the latest version (Personal) of Plato also "stopped working" on the Windows 8.1 machine.

Program builds on the Windows 8.1 desktop, using the latest personal versions of FTN95/Plato/salflibc.dll, have also encountered the "stopped working" errors when running on 8.1. And, if I remember correctly, these 8.1 builds have not encountered the error when running on a Windows 7 desktop. In recent history, all ZOOM program versions have been developed on a Windows 7 desktop using earlier versions of FTN95/Plato/salflibc.dll.

I've never received a message from a ZOOM user about a ZOOM program failure. Even with Windows 8.1, one can often exercise the program a lot before encountering the "stopped working" failure.

I've uploaded a folder containing the in-work upgrade of the ZOOM program. The folder contains the sub-folders and files that constitute the program package. The folder can be placed at a convenient location on the hard drive and the program can be executed by double-clicking the executable file in the folder.

The upgrade version of ZOOM can be downloaded at:

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

This upgrade is considered complete (except for the contextual help files), meaning that I don't know of any further modifications that are needed.

I'd appreciate any comments and suggestions you may have, including those based on your exercising of the program.
_________________
David Williams
Retired Aerospace Engineer
Huntsville, Alabama
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Apr 06, 2015 9:21 pm    Post subject: Reply with quote

On re-reading the thread from the start it looks like you are using a dreadfully old version of FTN95. Is it worth trying a newer one - say the PE?

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



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

PostPosted: Mon Apr 06, 2015 10:21 pm    Post subject: Reply with quote

Eddie,

All of the ZOOM development work (in more recent times) has been done on a Windows 7 desktop using the following versions of FTN95/Plato/salflibc.dll:

5.5.0.0 / 4.3.0.0 / 12.2.27.2

When running the developed executable on an XP machine, an older Salflibc.dll version is required (6.11.16.20). I don't know which operating systems the various users of ZOOM have, but none of them has ever complained of program failures.

A few weeks ago I downloaded the available PE FTN95 onto my Windows 8.1 desktop. The FTN95/Plato/Salflibc.dll versions are 7.1.0.0 / 4.6.4.0 / 16.4.27.11

Frankly, I don't like the new Plato as well as the old one. When the new Plato window is displayed after being minimized, it is corrupted beyond use, and I have to close it and reopen it.

The executable program that is created with the latest PE FTN95 on the Windows 8.1 machine has also failed on the Windows 8.1 machine, but, if memory serves, that same executable has run without error on the Windows 7 machine.

When all the failures to date (including a failure of the new PE Plato on the Windows 8.1 machine on one occasion) are taken into account, it appears (superficially at least) that there is some incompatibility between FTN95 and Windows 8.1 that is affecting ZOOM. Of course it is possible that there is something wrong with the ZOOM code, some insufficiency in the older version of FTN95 being used in development, or even something out of whack with my new Windows 8.1 desktop configuration that is causing the problem. But I don't really think so.

One reason that I gave the link for download of the latest ZOOM upgrade (not yet released) is to see if someone else on a different Windows 8.1 machine may not experience the "stopped working" error. I should also note that one can be somewhat productive with ZOOM on a Windows 8.1 machine. He just has to be aware that the "stopped working" error may occur. So far, the error has never occurred while the program is crunching numbers to determine the quasi-optimum trajectory.

I appreciate all of your comments and suggestions.
_________________
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 Previous  1, 2, 3, 4  Next
Page 3 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