Property sheet crash

Dan

I suggest that you check to make sure that you are doing a clean rebuild of your executable. There is just no conceivable way for you to get a traceback that lists these routines when you don't call them.

John

There is no return after printing a traceback. It may be possible to provide one but if it is possible then it would require a major extension to the current mechanism. You could force an exception to be raised (e.g. i = 0; i = 1/i) but I guess that is not what you have in mind. With 32 bits there are exceptions that you can trap and from which you can recover but we don't have that yet for 64 bits.

Thanks for the help, guys.

Paul, what means clean rebuild? This %PS crashes steadily with 100% probability happening during more then a dozen years on half a dozen new computers with new installations of compilers including 32 and 64bit and different OSes.

One more hint, since attention to subtle details is important: the 32bit ftn95 compiles ok but the 64 bit one can not compile %ps when /undef is used crashing with the odd diagnostics at :

Winio@('%15^`ps[hot_track]&', ish1, ish2, ish3, ish4, ish5, ish6, ..., ish15, icChosenTab, cbUpdateControl)

'Argument number 4 (ISH3) of WINIO@ should be a call-back function.'

Which potentially means that my program succeeded to make young 64 bit compiler some brain damage 😃

Dan

For me a clean rebuild is when all the code is recompiled, new object files are created and hence the executable relates to the whole of the source code in its current state.

In your words about clean rebuild i hear cultural differences. For your everyday work you probably use some crappy and slow C/C++ while i use excellent and fast FTN95 😃. Clean rebuild is exactly how I mostly do almost every time since the entire code compilation is just 5 seconds which made me lazy even to think about speeding up this further. To remove potential dependency on the order with modules I even sometimes recompile twice.

I suspect that when i close property sheet and return to the main program when crash happening immediately, the crashing function is trying to get parameters and variables but they are not defined by some reason be it a bug in the code or in the Clearwin+. I'd still suggest to modify DLL and perform the check of all such input parameters in these two crashing functions like we discussed above and if they look utterly crazy issue a warning with possible reasons and instead of allowing to further crash just don't execute these functions. Nothing too harmful will happen and the user will know the possible remedies. Crashes in Clearwin are unacceptable. By itself such functions are called very rarely in any code, and allowed to be slow as they are performing at the speed of reaction of the humans and all we have 5 ms 'resolution' at the best, 1000x slower then slowest Clearwin function

Clearwin has to stop crashing and giving crashing binary addresses like in stone age computing. Even pro users can not tell anything by such addresses since the sources of Clearwin libraries are unavailable. It has to have updatable database of users' experience in regular English when one or another bug is happening. To be adopted by everyone Clearwin+ must literally babysit its every user. Instead it sometimes punish heavily even the most loyal adopters.

UPDATE: just after i wrote above '...By itself such functions are called very rarely in any code, and allowed to be slow as they are performing at the speed of reaction of the humans and all we have 5 ms 'resolution' at the best, 1000x slower then slowest Clearwin function...' and immediately got my property sheet became slow like hell opening for 6-7 seconds instead of the previous whole life almost instantly ! Truly !@#$% devilry...

John, Ish3 is correctly 4th argument, no problem, the brain damage was why compiler decided that it has to be a callback.

It is hard to see the entire crash message, after showing what I already posted it freezes, hiding the rest. Will compare two such crash addresses, but first impression that all was the same with and without removing offended function from my code.

My files have no CallWindowProcW

Devilry Update: I was just sending you PM and when I clicked Send my Android Google Nexus cellphone froze like my code after closing property sheet.:). Phone then rebooted like it was in the glorious times of DOS and FTN77 when any errors putted entire computer down 10 or more times per day. Don't remember I had phone freezing before, specifically own Google ones. And that's not all: i got message from Google that someone accessed my account with IP not from any of my devices...Absurd

Dan

I have fixed the false error report about the 4th argument. This will appear with the next release of salflibc.dll.

A have also looked through the code that you posted at the start of this thread. I can't find anything that is fundamentally wrong with the code but it seems to me to be too complicated. In particular I would be concerned about the interaction between the plotting and the settings window.

At the very least I recommend that you change all the callback return values from 1 to 2. Also remove the call to see_propertysheet_page@ since this happens anyway. These two changes will reduce feedback and might prevent the overloading that is presumably causing you problems.

The SAVE at line 14 doesn't appear to do anything but is not needed anyway.

I can't get your sample to fail when running for 32 bits. For 64 bits, I changed khwCtrlSettingsMain to INTEGER(7) and then it runs OK.

I hope that this response does not open up another 'can of worms'. If there is a demonstrable error in ClearWin+ then I am happy to fix it but otherwise I am assuming that there is a fault in your larger program or that the interaction between the plotting and the settings becomes unstable with each somehow feeding back into the other.

Thanks Paul, Hopefully your fixes by chance will fix crash problem of my larger %PS too. Yes, the example above works fine, it is not working only as a part of larger code with thousands and thousands other Clearwin controls

In my codes there were total three %PS sheets all at some point causing instability (one for example did not react on OK/Candel buttons correctly which are closing %PS) and crashes (mostly when the sheets became very multi-tabbed). One was for some time solved adding SAVE statement (which was your suggestion around a decade ago and it worked until %PS got even larger) and two others are still not completely resolved but good is that the workarounds how not to crash were found (one is to always use debugger nothing else but just to start the code which is a bit strange but it is doing the job)

May be this behavior is not specific to %PS and the reason is somewhere else. The %PS usually by its nature collects thousands of other Clearwin+ controls, and bad things happening somewhere may put %PS down like recent finding with undefined input variable %ls showed.

I cleaned a lot of things inside %PS and tried changing all related subroutines it uses including most of ones you have suggested avove. Difficulty this specific %PS is huge and interrelated with the code so the extracting it from the code took few days and many attempts. I counted 20000 controls a decade ago. As now the extracted into demo the %PS does not crash, it crashes only inside larger code. I will try to make finally the smallest possible demo of this entire code and see if the error will be easier spotted there. But do you plan to add the possibility to check undefined variables which go as a input variables for Clearwin+ controls?

Quoted from PaulLaidler At the very least I recommend that you change all the callback return values from 1 to 2

Dan,

I think this may be very useful advice, as a call back response of 1 can do a lot of unnecessary screen updates. I am in the process of implementing this change to respond to other devilry I have located. You may see my recent post of problems when using export_image@. It wasn't this routine as I did some changes to file open/close and I scared off the devilry (for the moment). I am now cleaning up the interrupt responses throughout the program.

John

John, Thanks for reminding as I often do not care about this. After checking the code it looks like I have done that for all functions called by %PS couple years back when this issue with them =1 or =2 surfaced. And since this did not change anything of course I'm kind of semi-forgot about this. May still miss this somewhere in damn amount of used functions. Will try to enforce further cleaning searching around 'end function' statements when I will have sleeping difficulty 😃

One other thought...

If a 'Settings' dialog is somehow causing instability because of multiple calls to callback functions then you could consider forming a more stable environment by creating the 'Settings' dialog just once. You would hide this dialog instead of closing/destroying it and show it rather than recreate it. In this way the connection between this dialog and its variables in your code would be fixed and permanent. In theory it ought to make no difference but there is apparently something nasty going on because of the way in which your callbacks are interacting.

Quoted from PaulLaidler One other thought...

If a 'Settings' dialog is somehow causing instability because of multiple calls to callback functions then you could consider forming a more stable environment by creating the 'Settings' dialog just once. You would hide this dialog instead of closing/destroying it and show it rather than recreate it. In this way the connection between this dialog and its variables in your code would be fixed and permanent. In theory it ought to make no difference but there is apparently something nasty going on because of the way in which your callbacks are interacting.

Paul, I use opening and closing property sheet to save settings after changing something. By the way, how to hide the entire window?

The simple and direct way is to call the Windows API ShowWindow.

include <windows.ins>
integer ir
integer(7) hwnd
ir = ShowWindow(hwnd, SW_SHOW)
ir = ShowWindow(hwnd, SW_HIDE)

Cool, will play with this option too. Thanks, Paul

Dan

A bug has been identified in the ClearWin+ code for %ps and this is likely to be the cause of the failure. I will post a message when a new set of DLLs becomes available. I can do this soon as long as it is understood that there will be no significant changes for %pl and %fr.

This was the most annoying bug in Clearwin, true devilry. 'Was', if it really was catched, I cross my fingers. What could be more bad then to have the bug which disappears when you start the program inside the debugger?

It disappears in debugger even if you compile the code with /nocheck , so this is how I used the code for more then a decade, always running it via debugger. And this is how I discovered that besides of this error the debugger is actually very very useful.

Of course for this exact problem debugger did not find the bug, it was hiding it out at least I was able to run the code

Here is shortest version of crash of property sheet. This could be not the same as in my large code where property sheet crashes but it still crashes and it should never do that no matter what. Of course i can make it not crashing by the tricks but the point is not to hide but to find this very deeply hidden reason for the crashes. Hints:

1. If you add SAVE statement it does not crash (my larger code still crashes). Same if you compile it with /SAVE it does not crash (but again my larger code still crashes. The only way to make my larger code not to crash is to run it via SDBG even if it compiled with /NOCHECK and /OPTIMIZE. This does not influences its speed but creates an obvious inconvenience to always use SDBG)
2. If you remove kpol6 and associated %rd it does not crash
3. if you compile it with the /check it will inform that you forgot to define some values. Behavior though is the same like with or without kpol6
4. if you substitute one line in main program with another (uses button to call property sheet) it does not crash
5. If you compile my larger code with /undef it does not reveal any problems still it crashes. So the problem is most probably inside the property sheet source code

Code is in the next post

/* Didn't I mention before that anyone who is not using property sheet is losing a lot and their programs most probably look like sh#t and are barely usable?

CONTINUE from previous page.

COMPILING: FTN95 aaa.f95 /link or FTN95 aaa.f95 /link /check

module mod1
INCLUDE <clearwin.ins>

integer:: kpol1=1, nAxialSlices=1, n_CurrSheetSettings=1, kPrintScreenLoadedDensity=1
integer (7) khwCtrlSettingsMain
real*8 SIZEINCRFORZ1

Contains

   integer*4 function MainSettings () 
!         save

!....... one of sources of Access Violation if n_CurrSheetSettings not set (= 1)

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

        i = winio@('%ca[&Selection]&') 
      i=winio@('%1.3ob[raised]&')

i=winio@(' nAxialSlices %ta%9rd%ff&', nAxialSlices)

      i=WINIO@('%cb&')

i=winio@(' Factor and RGBA Colors to highlight Z1%ta%9rf %ff&', SizeIncrForZ1)

      i=WINIO@('%cb&')

i=winio@(' Print after read densities to text window %ta%rb[PrintScreen Density]%ff&', kPrintScreenLoadedDensity)

      i=WINIO@('%cb&')
	
	
        i = winio@('%sh',ish2) 

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

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

        i = winio@('%ca[Debug]&') 
!   if remove kpol6   - not crashing
	I = winio@('kpol1 ... 6 %ta%4rd%4rd%4rd%4rd%4rd%4rd %ff&', kpol1, kpol2, kpol3, kpol4, kpol5, kpol6)
        i = winio@('%sh',ish6) 

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

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

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

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

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

        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@('%hw&', khwCtrlSettingsMain) 
        m = WINIO@('%lw', lwCtrlSettingsMain) 
10000   MainSettings = 2 
   end function
!....................................................
INTEGER*4 FUNCTION cbupdateSettings() 
   call see_propertysheet_page@ (n_CurrSheetSettings) 
   cbupdateSettings=2 
end function
end module mod1
!====================================================
Program CrashingPS
use mod1

!.... With this line it crashes
i=winio@('%mn[File[Settings]]%es', MainSettings ) ! variant1	 crashes

!.... With this line instead previous one - not crashing
!i=winio@('%ww%^bt[Settings]%es', MainSettings ) ! variant2 not crashing

end program

Dan,

Your example is beyond my comprehension, especially with the selection of accelerator keys. I am finding that by changing to the following I am changing the response. Basically I declared all the variables used in the table as static (save) in the module. (I could/should have also given them an initial value?) You have these variables dynamic and so re-allocated on the stack for each call to MainSettings, with no initialisation. Does this make sense ?

module mod1
INCLUDE <clearwin.ins>

integer:: kpol1=1, nAxialSlices=1, n_CurrSheetSettings=1, kPrintScreenLoadedDensity=1
integer (7) :: khwCtrlSettingsMain  ! ,lwCtrlSettingsMain not needed ?
real*8 SIZEINCRFORZ1

  integer :: ish1,ish2,ish3,ish4,ish5,ish6,ish7,ish8,ish9,ish10,ish11
  integer :: kpol1, kpol2, kpol3, kpol4, kpol5, kpol6, lwCtrlSettingsMain

I don't understand the definition of call-back function in the following, but this might not be relevant ?

        i = WINIO@('%ff%cn%6`^bt[&OK]   %6^bt[&Cancel]&',&
     &  'set', lwCtrlSettingsMain, 0,&
     &  'set', lwCtrlSettingsMain, 0)

John,

Thanks for trying. Please confirm that my code crashes with your set of compiler/computers.

If i initialize all kpol variables the %PS does not crash but the point is that something will always will be not initialized, some elements of arrays for example, when your property sheet will become super large. And it will crash.

For example I do not know what is not initialized in my larger code, everything is checked many times in decade, but one of my property sheets crashes 100% if not run via SDGB. I do not know what specifically SDBG may do with the code compiled with /nocheck but it 100% prevents property sheet from crashing - this is good hint for SF to check. I hope SF will somehow make some traps for the attempts of %PS to crash.

Clearwin code has never crash no matter what the error. For example OpenGL was made such a way that it never crashes. It may not plot anything if something is wrong, arrays violated, request to plot requires too much time and resources to complete etc, it will leave the screen black so you will be able to retry the plot but it will never crash

My 1 year old version of Clearwin still not always checks for all cases of uninitialized variables (can not install newest version because a lot of programs are permanently running), for example it does not check for SIZEINCRFORZ1 above. It might not check for some other cases and looks like %PS is sensitive to uninitialized stuff it handles

The ' 'set', lwCtrlSettingsMain, 0 ' is similar to 'EXIT' if you use %lw. I often use %lw in my codes to allow them to continue their run like nothing happened while you open property sheet and do something in it in parallel. Otherwise without %lw when you open property sheet the code run will stop and wait till you exit it. The %lw is useful in many other situations, for example when the warning will pop to inform you about something without stopping the code. You will close the warning window when necessary, or it will close itself or fade away after some time you define