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 Previous  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
PaulLaidler
Site Admin


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

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

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



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

PostPosted: Thu Feb 01, 2018 9:59 pm    Post subject: Reply with quote

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 Smile


Last edited by DanRRight on Thu Feb 01, 2018 11:51 pm; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Feb 01, 2018 11:50 pm    Post subject: Reply with quote

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



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

PostPosted: Thu Feb 01, 2018 11:55 pm    Post subject: Reply with quote

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



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Feb 02, 2018 5:46 am    Post subject: Reply with quote

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


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

PostPosted: Fri Feb 02, 2018 9:47 am    Post subject: Reply with quote

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



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

PostPosted: Fri Feb 02, 2018 6:19 pm    Post subject: Reply with quote

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 Smile


Last edited by DanRRight on Fri Feb 02, 2018 11:39 pm; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Feb 02, 2018 7:39 pm    Post subject: Reply with quote

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



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

PostPosted: Fri Feb 02, 2018 7:49 pm    Post subject: Reply with quote

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



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sat Feb 03, 2018 10:51 am    Post subject: Reply with quote

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


Proof of the brain damage .... isn't ISH3 the 3rd argument in the list ?????
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sat Feb 03, 2018 5:57 pm    Post subject: Reply with quote

set_mg_returnvalue is listed ... do you call that in your code ?
could the error be emanating from something therein ?

meaning that maybe a message is awaiting response which isn't forthcoming ?

Ahh - I see you mention this just above the image with the error code - so what about the function that is also listed : CallWindowProcW - what does that do ?
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sat Feb 03, 2018 6:10 pm    Post subject: Reply with quote

oh, maybe a good idea to check the exact Access Violation message error when you eliminate the call to GET_GRAPHICS_SELECTED_AREA , just in case there's a subtle difference when compared to the above posted error message when it's included.
Also could there be more than 1 call to that subroutine in your code that you've overlooked ?
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Feb 03, 2018 7:44 pm    Post subject: Reply with quote

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


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

PostPosted: Tue Feb 06, 2018 5:46 pm    Post subject: Reply with quote

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



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

PostPosted: Tue Feb 06, 2018 11:42 pm    Post subject: Reply with quote

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?
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 Previous  1, 2, 3, 4, 5  Next
Page 2 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