How to debug a ClearWin+ call?

I have a large program running with ClearWin+ that seems to run ok until I quit the program, and then I receive the following error message:

The instruction at address 1008d26b attempted to write to location f0f0f0f0

1008d253 increment_var(void)#70 [+0018] 1004ef76 call_function(<ptr>(func()ÄreturningÄint),<ptr>char,<ptr>void,enumÄlogical,enum [+0193] 100386f6 __yield_program_control [+0013] 1005de20 __temporary_yield [+0016] 100cc7d3 __winio [+203b] GUI!WINDOW_END - in file gui.f95 at line 690 [+002c] CPT_INTERFACE!TITLE_PAGE - in file cpt_interface.f95 at line 166 [+051d] MAIN - in file cpt.f95 at line 29 [+0035]

I am compiling using /FULL_DEBUG /BOUNDS_CHECK /DCLVAR and /CHECK_WINIO, but get a similar error message without those options. The last line of my code that is mentioned in the above (i.e., in file gui.f95 at line 690) is the following:

iw = winio$('')

which I use simply to end a sequence of winio@ calls. My code is about 100,000 lines, but I get this error even if I just start up the program, which generates a window with a few menu items, and then immediately exit.

I have little clue how to proceed further with identifying this problem. Any advice on how to try to locate the problem would be greatly appreciated.

1. try first /UNDEF. Now undefined variables in GUI may cause troubles and can be immediately revealed. Which is good. Before they were causing troubles and you never knew what it was. Then

2. end the GUI instead of your line you posted above with iw=winio@('%hw'), ihw) where ihw - has to be declared as integer (7) ihw

and see wheat will happen.

3. end the GUI again instead of same line you posted with

iw=winio@('%lw'), ilw)

where ilw - has to be declared as integer and see wheat will happen. Will it crash immediately as you start GUI?

The crashes at window closure are the tough ones to find.

Posting the winio@() statements and some explanation of the variables might help, unless the window is too complex.

Things that might be happening:

There is a variable attached to a window (for control) that was created on the stack (not /SAVE) and now that location contains this bit pattern as its address.

Using the %cc (with or without the grave modifier), there is some construct that was closed before you referenced it as part of the window closure. This asynchronous behavior is tough to find sometimes; might not always happen.

Just some thoughts.

4. and yes, Bill above mentioned SAVE. Try to add SAVE statement inside GUI subroutine as last one among all other declarations in the header, just one word: SAVE

This should not affect anything in other code since looks like you have GUI.f95 as separate sub

If all above home medicine will not do any cure, you have to ask the doctor Paul 😃

Also mecej4 likes all crashes with their specific hex addresses. For true fortraneers a day without crashes is just a wasted day. 😃 They will quickly find the problem, the 690 lines code is just for one tooth to chew. At the end you can make a smaller demo from it, it is doable. Unlike I have one similar crash problem in one of 6000 lines GUIs, that is the real trouble to reduce, good i found workaround

5. By the way, can you try to run your code via command

SDBG YOURPROGRAM.EXE

Will it crash? Mine stops crashing, hiding the possible bug, making debugging even more difficult

Simon

ClearWin+ makes a call to increment_var in response to a user call to the INC standard callback.

Hopefully you are using INC in your code. If you are then as a first step try using the SAVE attribute with the corresponding variable.

MANY thanks for all these responses. My code is 100,000 lines, hence I have not yet made the effort to isolate a small example!

But Paul's suggestion to look at 'INC' is just what I needed. The program only started crashing once I had included some 'INC' statements somewhere else and that are used in the creation of this complex window. I will try SAVE as a workaround until I can isolate the offending incremented variable.

Given DanRRight's observation about crashes and wasted days, I will try to remind myself that my work must be exceptionally worthwhile!

Solved! My subroutine receives a variable to increment as an optional argument, but I neglected to check whether it was present in one special case and so the specific call to winio@ had a spurious 'INC' callback function. That problem only occurred when I tried to quit the program using an accelerator key.

Many thanks again for all the helpful suggestions.

Simon, Can you or anyone else show any good example of INC use worth of applying it?

Hi Dan, I cannot easily extract some code, but I use INC for the following in my program for a couple of things:

1. Counting how many times. or simply just checking, whether a menu item has been activated, which I later use primarily to save a record of what program options and settings the user has decided to use;
2. As an alternative to using %dd - I recall having some difficulties with %dd a long time back, and decided to use INC instead, but that may be redundant now. There are quite a few built-in callback functions that I have never used, but I would never suggest removing them unless they were a maintenance headache for Paul!