|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2867 Location: South Pole, Antarctica
|
Posted: Tue Nov 10, 2009 4:27 am Post subject: 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
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2867 Location: South Pole, Antarctica
|
Posted: Tue Nov 10, 2009 4:35 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8018 Location: Salford, UK
|
Posted: Tue Nov 10, 2009 10:12 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2867 Location: South Pole, Antarctica
|
Posted: Tue Nov 10, 2009 9:31 pm Post subject: |
|
|
Thanks, Paul, your hint was in right direction, no damn crashes anymore...still investigating the specific reason |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2586 Location: Sydney
|
Posted: Wed Nov 11, 2009 6:27 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2867 Location: South Pole, Antarctica
|
Posted: Fri Nov 13, 2009 2:06 am Post subject: |
|
|
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 |
|
|
Heise
Joined: 13 Feb 2007 Posts: 5
|
Posted: Tue Nov 24, 2009 9:58 pm Post subject: access violation |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8018 Location: Salford, UK
|
Posted: Tue Nov 24, 2009 11:17 pm Post subject: |
|
|
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 |
|
|
Heise
Joined: 13 Feb 2007 Posts: 5
|
Posted: Tue Nov 24, 2009 11:37 pm Post subject: |
|
|
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 |
|
|
JohnHorspool
Joined: 26 Sep 2005 Posts: 270 Location: Gloucestershire UK
|
Posted: Wed Nov 25, 2009 9:01 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8018 Location: Salford, UK
|
Posted: Wed Nov 25, 2009 9:44 am Post subject: |
|
|
Thanks Heise. I have modified the help file accordingly. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2867 Location: South Pole, Antarctica
|
Posted: Wed Nov 25, 2009 11:59 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2867 Location: South Pole, Antarctica
|
Posted: Thu Jan 25, 2018 11:40 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2867 Location: South Pole, Antarctica
|
Posted: Mon Jan 29, 2018 8:44 pm Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2867 Location: South Pole, Antarctica
|
Posted: Thu Feb 01, 2018 12:17 am Post subject: |
|
|
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 |
|
|
|
|
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
|