soccer jersey forums.silverfrost.com :: View topic - Property sheet crash
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 

Property sheet crash
Goto page 1, 2, 3, 4, 5  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Tue Nov 10, 2009 4:27 am    Post subject: Property sheet crash Reply with quote

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

Code:

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


Last edited by DanRRight on Tue Nov 10, 2009 4:42 am; edited 3 times in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Nov 10, 2009 4:35 am    Post subject: Reply with quote

Code:
!---------------------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


Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Nov 10, 2009 10:12 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Tue Nov 10, 2009 9:31 pm    Post subject: Reply with quote

Thanks, Paul, your hint was in right direction, no damn crashes anymore...still investigating the specific reason
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2586
Location: Sydney

PostPosted: Wed Nov 11, 2009 6:27 am    Post subject: Reply with quote

Dan,

I don't understand your use of %ac in:
Quote:
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
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri Nov 13, 2009 2:06 am    Post subject: Reply with quote

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



Joined: 13 Feb 2007
Posts: 5

PostPosted: Tue Nov 24, 2009 9:58 pm    Post subject: access violation Reply with quote

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


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

PostPosted: Tue Nov 24, 2009 11:17 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Heise



Joined: 13 Feb 2007
Posts: 5

PostPosted: Tue Nov 24, 2009 11:37 pm    Post subject: Reply with quote

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:

http://forums.silverfrost.com/viewtopic.php?t=1452

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



Joined: 26 Sep 2005
Posts: 270
Location: Gloucestershire UK

PostPosted: Wed Nov 25, 2009 9:01 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Wed Nov 25, 2009 9:44 am    Post subject: Reply with quote

Thanks Heise. I have modified the help file accordingly.
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Wed Nov 25, 2009 11:59 pm    Post subject: Reply with quote

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



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

PostPosted: Thu Jan 25, 2018 11:40 pm    Post subject: Reply with quote

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



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

PostPosted: Mon Jan 29, 2018 8:44 pm    Post subject: Reply with quote

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



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

PostPosted: Thu Feb 01, 2018 12:17 am    Post subject: Reply with quote

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.
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 -> ClearWin+ All times are GMT + 1 Hour
Goto page 1, 2, 3, 4, 5  Next
Page 1 of 5

 
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