forums.silverfrost.com

[DanRRight]

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

[DanRRight]

[PaulLaidler]

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.

[DanRRight]

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

[JohnCampbell]

Dan,

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

[DanRRight]

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 )

[Heise]

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

[PaulLaidler]

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.

[Heise]

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

[JohnHorspool]

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

[PaulLaidler]

Thanks Heise. I have modified the help file accordingly.

[DanRRight]

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

[DanRRight]

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.

[DanRRight]

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

[DanRRight]

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.