Property sheet crash

OMG, i've spent a week to find the reason why this code is crashing with the same Call Stack Status access violation problem?

I've tried to scale it down whole week to be small, here it is.

Click Graph, then click somewhere on the graph area and press F2. When property sheet appears, close it by pressing OK (or the same does Esc to close it). It crashes

If Graph is not in the focus though you can open and close property sheet no problems pressing Settings on main window. It also works if number of property sheet tabs is less then 11, but in main code where there is a lot of other things 10 is also not working)

combine two parts

module all_declars

      integer kFinishedStatus, ilwGrWinDOWActive, lwCtrlSettingsMain, khwCtrlSettingsMain, kRun
      integer n_CurrSheetSettings
      real*8 progressBar

      integer lx_GrWindow, ly_GrWindow, &
      iDOWPosYaxisRightFromRight, iDOWPosYaxisLeftFromLeft, &
      iDOWPosXaxisTopFromTop, iDOWPosXaxisBottomFromBottom,&
      iVolPosYaxisRightFromRight, iVolPosYaxisLeftFromLeft,& 
      iVolPosXaxisTopFromTop, iVolPosXaxisBottomFromBottom

  SAVE  
  CONTAINS
end module all_declars

!==================================================================
  Program QTst
  use clrwin
  use all_declars 
  integer Settings, cb_DOWGraph  ,LongRun
  external Settings, cb_DOWGraph ,LongRun
  lwCtrlSettingsMain = 1111
  kFinishedStatus = 1
  n_CurrSheetSettings = 1
  ilwGrWinDOWActive= 1

!---
  i=WINIO@('%ww%bg[btnface]&')
  i=winio@('%sf%ts&',0.8d0) 
  i=WINIO@('%mn[File[Exit]]&','exit')
  i=WINIO@('%mn[Settings[Main Options]]&',Settings) 
  i=WINIO@('%ac[F2]&',Settings) 
  i=WINIO@('%ac[F3]&',cb_DOWGraph) 
  i=WINIO@('%ac[esc]&','exit')
  i=WINIO@('%ac[Alt+X]&','+','set',ilwGrWinDOWActive,0,'+','set',kRun,0,'exit')
  i=WINIO@('%nr%nd&')
  i=WINIO@('  %^tt[Graph] &',cb_DOWGraph)
  i=WINIO@('  %^tt[Settings]%ff&',Settings)

  i=WINIO@('%pv%`bg%120.40cw[hscroll,vscroll]&', rgb@(224,224,255), luncw1)
  i=winio@('%pm[Save Highlighted Text in Clipboard'//char(9)//'Ctrl+C]&',  'COPY' )
  i=winio@('%pm[Paste Clipboard Text'//char(9)//'Ctrl+V]&','PASTE')
  i=winio@('%ac[Ctrl+C]','COPY')

10000 continue
     end	

!-----------------------------------------------------
    integer function cb_DOWGraph ()
    use mswin ! clrwin
    use all_declars
    integer  mouse_pos, Settings
    external mouse_pos, Settings

    CALL PERMIT_ANOTHER_callback@()

    lx_GrWindow=600; ly_GrWindow=400
    jj=WINIO@('%ww[no_border]%bg[btnface]&')
    jj=WINIO@('%ac[Alt+X]&','+','set',ilwGrWinDOWActive,0,'+','exit','set',ihwGrWinDOWActive,0)
    jj=WINIO@('%ac[F2]&',Settings) 
    j = winio@('%pv%^`gr[rgb_colours,black,box_selection,user_resize,full_mouse_input]&',& 
    &    lx_GrWindow, ly_GrWindow, ihwGrWinDOWActive, mouse_pos) 
!    j=winio@('%lw[owned]',ilwGrWinDOWActive)
    j=winio@('%lw',ilwGrWinDOWActive)
    cb_DOWGraph = 1
    end function cb_DOWGraph

!-------------------------------------------------------
    integer function  mouse_pos ()
    include <windows.ins> 
    integer plotDOWGraph
    external plotDOWGraph 
    jj=plotDOWGraph()
    mouse_pos=1
    end function mouse_pos

!---------------------plotDOWGRAPH ---------------------
    integer function plotDOWGraph ()
    use clrwin
     kolRed = rgb@(255,155,155)
     CALL DRAW_LINE@ (1,1,300,300, kolRed)
    plotDOWGraph = 1
    end function plotDOWGraph 
!----------------------------------------------------------------
	integer*4 function Settings ()
        use clrwin
        use all_declars 

	integer  cbupdateSettings
	external cbupdateSettings

!       CALL PERMIT_ANOTHER_callback@()

!....... source of Access Violation ERROR: Not set n_CurrSheetSettings = 1

        i=winio@('%sy[3d_raised]&')
        i = winio@('%ca[&Main]&')
        i = winio@('%sh',ish1)

        i = winio@('%ca[&Selection]&')
        i = winio@('%sh',ish2)

        i = winio@('%ca[&Stocks]&')
        i = winio@('%sh',ish3)
 
        i = winio@('%ca[Sound]&')
        i = winio@('%sh',ish4)

        i = winio@('%ca[&After 4]&')
        i = winio@('%sh',ish5)

        i = winio@('%ca[Dow]&')
        i = winio@('%sh',ish6)

        i = winio@('%ca[Volume]&')
        i = winio@('%sh',ish7)

        i = winio@('%ca[Misc]&')
        i = winio@('%sh',ish8)

        i = winio@('%ca[Res.]&')
        i = winio@('%sh',ish9)

        i = winio@('%ca[Res.]&')
        i = winio@('%sh',ish10)

        i = winio@('%ca[Res.]&')
        i = winio@('%sh',ish11)

!        i = winio@('%ca[Res.]&')
!        i = winio@('%sh',ish12)

!        i = winio@('%ca[Res.]&')
!        i = winio@('%sh',ish13)

!        i = winio@('%ca[Res.]&')
!        i = winio@('%sh',ish14)

!        i = winio@('%ca[Res.]&')
!        i = winio@('%sh',ish15)

!        i = winio@('%ca[Res.]&')
!        i = winio@('%sh',ish16)

!        i = winio@('%ca[Res.]&')
!        i = winio@('%sh',ish17)

!        i = winio@('%ca[Res.]&')
!        i = winio@('%sh',ish18)

!        i = winio@('%ca[Debug]&')
!        i = winio@('%sh',ish19)

!        i = winio@('%ca[Weights]&')
!        i = winio@('%sh',ish20)

!        i = winio@('%ca[READ_URL]&')
!        i = winio@('%sh',ish21)


        i = winio@('%^`11ps&',ish1, ish2, ish3, ish4, ish5, ish6,&
     &  ish7, ish8, ish9, ish10, ish11,   &
     &  n_CurrSheetSettings, cbupdateSettings)

        i = winio@('%ww%bg[gray]&')

	i = winio@('%ac[Esc]&',   'exit')
	i = winio@('%ac[Alt+X]&', 'exit')

        i = WINIO@('%ff%cn%6`^bt[&OK]   %6^bt[&Cancel]&',&
     &  'set', lwCtrlSettingsMain, 0,&
     &  'set', lwCtrlSettingsMain, 0)
!        m = WINIO@('%lw[owned]&', lwCtrlSettingsMain)
        m = WINIO@('%hw&', khwCtrlSettingsMain)
        m = WINIO@('%lw', lwCtrlSettingsMain)
10000	Settings = 1
	end
!----------------------------------------------------------------
        INTEGER*4 FUNCTION cbupdateSettings()
        use clrwin
        use all_declars 
        call see_propertysheet_page@ (n_CurrSheetSettings)
        cbupdateSettings=2
        end

Try using /SAVE as a test on the FTN95 command line. If this fixes the problem then it means that a local variable has been accessed after it has gone out of scope. Remove /SAVE from the command line and apply it selectively to the local variables until the problem is fixed.

The most common failure of this kind is when a %lw control variable is used.

If that does not work, let me know and I will have a look at your code.

Thanks, Paul, your hint was in right direction, no damn crashes anymore...still investigating the specific reason

Dan,

I don't understand your use of %ac in:

i=WINIO@('%ac[Alt+X]&','+','set',ilwGrWinDOWActive,0,'+','set',kRun,0,'exit')

jj=WINIO@('%ac[Alt+X]&','+','set',ilwGrWinDOWActive,0,'+','exit','set',ihwGrWinDOWActive,0) 

What does this do ?

Also, does the variable 'ihwGrWinDOWActive' cause any problems ?

John

Setting of ilwGrWinDOWActive to zero is factually the same as closing the window controlled by %lw (ilwGrWinDOWActive). it is done to close both main and graphics window with one single movement when exit to Windows

Setting ihwGrWinDOWActive to zero is really unneaded and does nothing useful, just forgot to remove it when experimenting. No, it is not causing the crash

I've tried a couple dozen additional variants, and still did not solve the problem causing this crash. The code only works if i add SAVE in the Settings function

%ps is pretty sensitive function, it caused me a hell of troubles over time, it is kind of not error-resistant function, which punish you with the crash. If you forgot to set the value for n_CurrSheetSettings for example (left undefined) it crashes and you loooong scratch the head finding the problem

( Talking on the most idiotic bugs or crashes, the most of the lost time caused me one old subroutine used for decades DRAW_LINE@(ix1,iy1,ix2,iy2,icol) which was drawing me blinking line for a long time ticking on my nerves. I've done everything to find the reason until realized very recently finally that it 'eats' undefined variable icol without any hiccup. It better would crash! And some unknown crazy icol value, may be negative, i do not know, caused it to blink like XORed when you call the same window repeatedly or use full_mouse_input . Compiling and debugger with /undef did not inform me of undefined variable. You can reproduce this bug commenting the line in the code above kolRed = rgb@(255,155,155)

And i did not yet solve this simple problem which sometimes appears and debugger keeps mum why. Probably draw_line@ has something not yet cleaned up or i have some my own bug. Will report when find the problem

http://img24.imageshack.us/img24/6230/drawline.png

I also have pretty large piece of the code which became unusable after i added something there and it now crashes. It creates tree_views which if you tried them are pretty tricky. I do not use it for 5-7 years, and back then i suspected it was compiler stability problem with all that Fortran 90 syntax. And very hard to scale down 20 thousand lines to find the bug. Probably will take a look there again, since the recent FTN95 compiler polished by the numerous users became very stable )

I have encountered a similar access violation. In my code, I open a separate window to display an image, making use of %lw to keep the window open.

The error would occur when closing the window, but only if I used the X in the upper right corner. If I closed the window using the menu (which uses the built-in EXIT callback function), no error would occur.

Using /SAVE while compiling eliminated the problem. I have not further isolated to a particular variable reference.

Interestingly, I only recently encountered this problem, even though I have not made any substantial changes in the code. I have recently upgraded to FTN95 5.40, from 4.80. I have read elsewhere (see 'Version 5.40 problem?' thread) that ver. 5.40 may be more particular in this regard.

Heise

There is no reason to think that this will depend on the version number of FTN95. Your control variable for %lw needs to have the SAVE attribute if it appears in a subroutine. The failure occurs when this variable is accessed after its storage has been released.

Perhaps not -- and I am not trying to assert that there isn't a programming error -- but the symptom was not observed until upgrading the compiler, and this observation is consistent with what Bill reported in his thread:

https://forums.silverfrost.com/Forum/Topic/1191

Might I suggest adding a note in the helpfile for %lw about the need to use the SAVE attribute with the control variable, since, as you stated earlier, %lw seems to be the most common cause of this failure?

Thanks, Heise

Heise,

Have you considered using %cc to intercept window closure using the X ?

You then have a choice of actions on how to proceed:-

1). Do nothing, effectively disabling the X

2). Close the window by setting the control variable to zero

3). Ask the user for closure confirmation and then proceed to do either 1) or 2) above.

Cheers John

Thanks Heise. I have modified the help file accordingly.

Can someone confirm that this code above does not crash if you save lw control variable lwCtrlSettingsMain? It still crashes in my case. Only SAVE alone statement to save everything in the function SETTINGS saves it from crashing. SAVE just lwCtrlSettingsMain in this function or in the module does not change anything

Remember I offered $200 for fixing this bug? This devilry is finally pesticided.

There are two reasons %ps becomes unstable and crashes:

1. when %ls has undefined parameter which (because FTN95 does not checks undefined variables in Clearwin+ controls) gets not caught by the /UNDEF switch.

2. But most pain caused just using %ob[raised] / %cb in the property sheet tabs. PS could crash or not if its code becomes very large, and uses many tabs. Sometimes %ps crashed after several calls. This bug made my life miserable until I found workaround and it was hidden for the last 10-15 years. The 64bit did not fix it, as I hoped, so I started to check everything and finally found the reason.

Before that the workaround was to always run the code under debugger SDBG even if programs were compiled with /NOCHECK. This was annoying but finding this bug was a hell.

THIS IS WHY WE NEED MUCH MORE USERS TO POLISH THE COMPILER. And users always have to share their experience!

Don't be lazy, tell about difficulties and findings which caused you troubles!

Even more pain was that this bug did not appear when John-Silver for example tried to run the code on his computer. I owe him case of beer or bottle of whiskey anyway.

Alas, I was wrong and devil hiding in the code for decades escaped again. I succeeded on small extraction of the code but removing %ob/%cb from main large code gave no effect. Same with %ls/%ms.

Does this error tell anybody anything? The crash mostly gets after I close %PS either in get_graphics_selected_area or set_mg_return_value. There is no such subroutines in the code, the get_graphics_selected_area@ all are removed. Will remind that there is no crash ever if I run the code via debugger.

I can not supply the demo code. As soon as i do extract the %PS containing function into separate demo the bug disappears.

One thing has to be done in Clearwin+ to make it more friendly and more crash-resistant : it has to check if variables supplied by the user are defined and if they are not then with /UNDEF it has to complain about this. If Clearwin control has variables which are output of the control - it's ok, it can be left undefined until it is used by the user. This improvement will not break any existing codes.

Currently with the Clearwin+ the FTN95 is doing something which is out of step with the ideology of FTN95: it checks undefined variables only in the users code, not in the Clearwin controls. So if some variable InpVar within winio@('%xx', InpVar, OutpVar) is undefined, the FTN95 will not tell you.

Here is demo example which may or may not crash if compile it with /check or /nocheck but if compile it with /undef or /checkmate it crashes. This happens because one variable namFarraysize defining size of the array supplied to %ls is intentionally left undefined and compiled with the /undef the code has unreasonable input value causing crash

	winapp
	parameter (n_LSchoices = 10)
	character*32 NameFull(n_LSchoices)

	namFarraysize = n_LSchoices
        i = winio@('%ww%?22.10`ls[Name Full]%es', NameFull, namFarraysize, iOutpVar) 

	end

The image shows that something fishy happens in Clearwin+ DLL with these two its functions. First of all they never have to crash, no matter what, second they have to check input parameters and tell clearly what is wrong if it is wrong. This is GUI, nobody cares if these functions will be a bit slower by few nanoseconds. Much more important to supply more friendly information to the user.

Dan

Your traceback indicates that the failure occurred when you called GET_GRAPHICS_SELECTED_AREA@. Do you call this function? Is it being called by mistake?

On the face of it, this routine should not crash. If a graphics object is not currently selected then you should get an error report. If a graphics object is selected and an area in the graphics is not selected then again you should get an error report.

It seems like the graphics object in question has expired in some way but not cleanly.

GET_GRAPHICS_SELECTED_AREA@ is for %gr[box_selection] and similar %gr options. Maybe this routine is being used by mistake for something else.

Paul,

Yes, the code uses %gr[rgb_colours,gray,box_selection,user_resize] and the GET_GRAPHICS_SELECTED_AREA@. But the fun is that even if I remove GET_GRAPHICS_SELECTED_AREA@ commenting it completely out of the code, I get the same crash telling that the GET_GRAPHICS_SELECTED_AREA@ has a problem! That means this function has a problem or its input parameters have problem even if the problem actually is somewhere else in Clearwin DLL. It does not matter if my code has a bug or not, it must not crash. Crashing in Clearwin DLL means its design defect. Compiling my code with all /checks and /undefs tells no harmful superbugs. Before using 64bit I thought that in 32 bit mode the error may come due to arrays boundary fault due to stack problems. But now with 64bits that is not the case.

Does this hint tells you anything: there is no crash if I run the code via debugger (the code is compiled with /nocheck which means it's formally not for using with SDBG) ?

Would be great to make one addition to Clearwin+ that everything what goes as input for any Clearwin+ function have to be checked and if something crazy is supplied to it the function has to issue the warning, deactivate itself, but not crash. My wish is that Clearwin+ become completely crash-proof, user-friendly, fool-proofed, and instead of crash always generated popup window telling that the something like GET_GRAPHICS_SELECTED_AREA@ got a problem with the description like in my screenshot and all the above what you just mentioned as possible reasons and the offer to continue execution or stop. That how ideal CWP has to look for the average user. So far all who use it extensively yell and swear like drunkards 😃

Dan

There is no comprehensible way for your code to fail within GET_GRAPHICS_SELECTED_AREA@ (as shown in your traceback) if your code does not call GET_GRAPHICS_SELECTED_AREA@.

This routine is isolated within the library. In other words it can't be called via another routine in the library. So it must be called from your code.

This is also true for SET_MG_RETURN_VALUE@ which is the preceding call.

Perhaps the traceback is not complete and the failure is actually occuring after and not within your call to GET_GRAPHICS_SELECTED_AREA@.

It is quite possible that using the debugger is not a viable option in which case it may be necessary to plant some diagnostic feedback into your code. I sometimes use calls to the API MessageBox function for this purpose. A simpler approach is just to use Fortran PRINT statements together with a divide and conquer approach.

Will check again if all was compiled right way. I tried to remove parts of the property sheet one by one - this did not give me any clue as the only what happened was that with one or two tabs it works OK and with 3 or more it crashed if invoke %ps second time. With more tabs it crashes after one call.

The PRINT will not show here anything peculiar because the crash takes place at the moment when I close the window containing %PS and return to the main program window. That means that something in Clearwin DLL might happen long before that moment as it does not check for example for undefined variables supplied to controls. One example is above with %ls.

UPDATE: I removed get_graphics_selected_area@ and even set_graphics_selection@ but the bug shows in get_graphics_selected_area exactly like it was before. Another strange thing is that there is no set_mg_return_value function in my code

Paul,

Is there a 'call report_traceback@' so the call-back trace can be reported. This might show where the program is at and indicate if the call stack is corrupted, assuming there is such a thing !

This would help DAN to plant this call in his code where he thinks the problem is and not rely on SDBG64

John