View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2818 Location: South Pole, Antarctica
|
Posted: Mon Apr 06, 2020 8:28 am Post subject: User friendly Clearwin error messages |
|
|
I got one more property sheet crashing (third during 20 years) and i can not find the bug.
Do people agree that Clearwin should always keep the debugging information about the line where error happening no matter if the code compiled with /nocheck or even /optimize ? So if crash happens the line information will be displayed in readable format, not with hex address or relative continuation #. This will not add much to the exesize or not make the code slower, the human-to-computer interactions are slow anyway and /optimize or /nocheck are useless in Clearwin where reaction on mouse or keyboard are of the order of 0.1 second
Currently Clearwin only gives the bug report of this sort "you got an error in continuation #146" suitable only for the future cyber brains in 22d century. And even worse recently i get the crashes with the error report "Invalid initial value for %rf format. Are you sure that variable initialized at address a1c0004423443344323656535677456234 ?" which no one can find besides may be with one month of efforts mecej4 but he does not use Clearwin.
Worst ever part is that when you run the program through the debugger to find the bug the error disappearing no matter which compiler switch was used even the /nocheck. If compile the code with check or undef the crash also does not happen even without debugger |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Mon Apr 06, 2020 8:59 am Post subject: |
|
|
Dan
When developing ClearWin+ programs you need to use at least /DEBUG in order to get line number information on trace back.
This information is only built into the executable when using /DEBUG or options that imply /DEBUG.
Basically, if you need this information then you have to ask for it because it involves an overhead that is undesirable in release mode. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2818 Location: South Pole, Antarctica
|
Posted: Mon Apr 06, 2020 8:00 pm Post subject: |
|
|
I always use /debug, even /full_debug when develop. As i wrote when /debug or /check or /undef is used the crash in %ps does not appear. If use /nocheck the code crashes but same code does not crash if run it through SDBG. Something is wrong with %ps. It does not allow to find the bug giving wrong error message. I suspect un-initialized variables may cause wrong message and the crash of this parts of the code which use %ps even though all variables used by all controls (like %rf %rd etc) are initialized variables. I mean, just the assignment at the end of file after all Clearwin GUI was completed like a statement A=B when B is not initialized ones caused the crash of my GUI with %ps.
As to not desirable additional debug information in the EXE file i agree but only for the Fortran text itself. Fortran is a language used, documented and polished by many people for decades. Clearwin is totally propitiatory, its logic, capabilities and complexity understands only its developer, all users just use it intuitively and good is that mostly it works great though sometimes you do not know how . As to overhead associated with additional Clearwin debug information is totally, i mean TOTALLY, negligible as it was developed in 1990th when harddrives were 1 GB in size and RAM in 10 MB range and nobody cared about exe sizes due to Clearwin even then. Since then all the Harddrive and RAM sizes grew not 20%, not 100%, not even 1000% but 4 orders of magnitude while EXE sizes remain approximately the same
As to slowdown associated with this a bit larger weight of exe files if you compile Clearwin code with /debug was not a problem even in 1990th with their toy computers based on 80486 as the response time of GUI even then was orders faster than human's 0.1 second lag.
Conclusion : loss of users time when we write and debug Clearwin code it the major problem with it. That so much limits its adoption and usabily, that i personally ready to give some GUI speed and exe size in favor of simplicity of finding of any problems. Actually even if my EXE size was not 20 MB but 200 i'd do not even blink an eye. Intel compiler EXE sizes always were many times larger than FTN95 ones and starting with middle of 1990th not a single user ever cared or complained |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Tue Apr 07, 2020 8:22 am Post subject: |
|
|
Dan
You keep going back to this issue and I have tried to explain to you that what you are asking for is just not feasible. There is nothing more that I can say. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Apr 07, 2020 9:19 am Post subject: |
|
|
Dan,
As you know, hunting down a bug is difficult if not impossible when we are given only a verbal description. You have to be willing to provide a "reproducer".
The chances of a reproducer leading to a successful identification of the bug are higher if the reproducer is smaller. You may have to spend some time in creating a small reproducer but in return you (and possibly other users with similar code) will be rewarded with not having to worry about the same bug giving you problems in the future.
Let's have that %PS bug reproducer, please? |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu Apr 09, 2020 12:25 pm Post subject: |
|
|
I don't think Dan is asking for nybody to 'debi=ug' this particular problem he has, he's just saying that basic info should be accessible (like line number where error occurs) so that the user can more effectively debug n the first instance without having to rely on the developinf entity's degugger (Paul) , or the more astute amongst the user-community (mecej4, for example) to analyse the problem for them.
While I appreciate the verity in Paul's statement that the overhead to output all DEBUG informationmight be considerable (depending on the program):-
a) I don't think Dan is asking for everything (it could be develpoed progressively)
b) an overhead wouldn(='t exist in the 'production compile' because one wouldn't use DEBUG for that (as all the (known) show-stopper bugs wold have been eliminated
Would it really be that difficult to include be able to output say just the line number where the failure occurred, for example ?
That on it's own would be a massive starting point, I would agree with Dan there. _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Apr 09, 2020 5:53 pm Post subject: |
|
|
John S., you said:
Quote: | an overhead wouldn't exist in the 'production compile' because one wouldn't use DEBUG for that (as all the (known) show-stopper bugs wold have been eliminated. |
For that to be true, there would probably have to be available two versions of the Clearwin library and DLL, one with traceback capability (i.e., the debug version) and the other without (the production version).
An analogous situation exists with the Microsoft Visual C compiler and libraries. There are debug and non-debug versions of many of the C libraries; for example, LIBCMT.LIB and LIBCMTD.LIB. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Fri Apr 10, 2020 2:07 am Post subject: |
|
|
I based my comment on comments I've seen before on the forum, not based on any experience as I have no need to use debug.
I thought everything was activated simply by the presence or otherwise of the /DEBUG.
Previous comments I've seen indicated that by calling the debugger the executable code was more ponderous/slower but that in 'production mode' (i.e. without the /DEBUG) it was hence faster.
I stand corrected.
Could this be the reason for those abnormlly slow polyhedron tes results then ? _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
|