forums.silverfrost.com

[PaulLaidler]

Dan

I think I did (too many balls in the air). If it concerned resizing then that bug has been fixed.

[DanRRight]

This was about sensitivity to the input data when native %pl crashed after simpleplot_redraw@ was used.

[PaulLaidler]

Dan

I have found your email, downloaded the archive and followed your instructions. The result is that I get "Reference to undefined variable" at line 3199 of crashPL.for. The variable is E3864_log(1) which is indeed undefined, at least according to SDBG64.

Am I missing something?

[DanRRight]

Most probably my instructions how to get the crash were not clear. The problem you see is because the data needs to be loaded first but it was not loaded, please load it first.

For simplicity I made just 3 tabs. Click first "Load Data", after data stops loading in couple seconds click "Working Case" button where in new window there are options to create few XY plots, you then can click any radiobuttons and see all works OK.

Close it using ESC and finally click on "Crashing Case" button, which is made programmatically similarly to the Working Case, and where you also will see few options to plot one or several XY graphs. You will see that initially all is plotted OK which tells that %PL is working OK but then clicking on any of radiobuttons causes crash because I suspect the simpleplot_redraw@ conflicts with something, most probably either being too sensitive to the data ranges or having a bug.

This whole demo was a simple case of using %PL when we have one set of X data and multiple sets of Y. The %PL makes one, two or several plots according to ON or OFF state of radiobuttons (multiplying specific Y(i) data on radiobutton state) and updating %PL with simpleplot_redraw@

[PaulLaidler]

Dan

I have spent an hour or so stepping through your program but at the moment I can't work out if there is anything wrong with %pl.

For me a failure occurs when I click on the "Plot case 1" radio button (to reset it) and it fails because the y-data to be plotted at this point contains at least one invalid floating point value. It's not out of range but some kind of NAN.

ClearWin+ should report a runtime failure (and this needs fixing) but after that I can't work out where the data is coming from. So maybe your data is invalid or %pl is not processing the data correctly.

The only thing that I can suggest at the moment is that you print out the data that you are plotting at this point to see it looks like.

[DanRRight]

Thanks for the hunt of this devilry bug. I naively expected that since you have the source code of native PL the bug will be immediately catched in your own debug mode in your compiler where native PL was written. But I always forget that all developers prefer C++ and respect to debugging live even in pre-Anderthals era

I will look again at all arrays but strongly suspect that the only way NaN can be generated is by native PL own bug. Because this small simple code can not generate such thing in /check /debug /undef mode after successfully plotting the same arrays when window starts (at start both rariobuttons are ON).

I spent more then a month to find the bug checking everything and extracting this demo from large code and together with my other 2 decades experience with plotters like my own, OpenGL and Simpleplot led me to wish the debug mode not only in Fortran (where FTN95 is the world champ among all existing compilers, most probably not just Fortran type) but in native PL plotter and then entire Clearwin+ too. For sure native PL must have it. User set some PLdebugkey=1 and native PL will inspect data before plotting and tell which array and where has the problem.

The same kind checking options for %ls and other Clearwin+ controls for example would reveal undefined parameter or out of range value. But this thing for Clearwin+ is definitely deeper in the wish list, for now I'm sure the native PL must have such checking options first to be user friendly. In my own graphics made using FTN95 and its graphics libraries I can immediately use /debug and find what crashes the code, the native PL also needs something like that because inside it is much more complex then draw_line_between@ or OpenGL plotting commands.

But having a crash if some problem without a human readable explanation is not acceptable for Fortran users, they are probably ok only for computer science geeks.

UPDATE
---------------
There is no way the data can have any NaNs. Before plotting all data is compared to be >1e-30 and if NaN happen at this stage the Fortran code would inform before invoking simpleplot_update@. So the error happens inside the native PL

[PaulLaidler]

Dan

I have an open mind as to where the fault lies.

If I put a print statement at line 3204...

[DanRRight]

Paul,

These zeroes were taken care of in the next block of lines to make sure that the data will be free of zeroes before call of function cb_Replot which calls simpleplot_redraw@

[PaulLaidler]

Dan

When I run your program in 32 bit mode there is an integer overflow and then some undefined values that show up. I don't know if this has any impact on the data that you plot.

[PaulLaidler]

Dan

I am beginning to understand the problem but I am not sure how to fix it at the moment.

We probably need two versions of SIMPLEPLOT_REDRAW@.

When using log scales the current SIMPLEPLOT_REDRAW@ is for use when resizing, and when the data has not changed but needs to be restored to what it was before the log transformation. This is not what you want in your program where you call SIMPLEPLOT_REDRAW@ for logarithmic data that has been changed.

So at the moment SIMPLEPLOT_REDRAW@ is not doing what you want in this code and it is presumably restoring old data that is no longer valid.

[DanRRight]

Paul,
Somehow older simpleplot_redraw@ was doing both rescaling and refresh. It probably had a restriction new simpleplot_redraw@ does not have: in multi-plot the first array always must define Y_max

As to overflow if size(array) and undefined some variable in 32bits, these seems are two bugs of FTN95. First one should be either error or zero, as the array is not yet allocated. And second error is indeed due to undefined values and 32 bit compiler catched it while /64 missed. Currently FTN95 /64 still misses a lot undefined variables.
Both lines can be commented out, they are not used. There are some other undefined variables all of which can be initialized as =0. This does not change the fact that simpleplot_redraw@ crashes even in 32bits due to possibly the reason you have just mentioned.

John, Yes, the new name plot_redraw@ or pl_redraw@ has to be introduced.

[PaulLaidler]

Dan

I think that a new routine is the simplest option and I have called it PLOT_REDRAW@.

[PaulLaidler]

Please see...

http://forums.silverfrost.com/viewtopic.php?t=3827

[DanRRight]

Thanks, Paul for the efforts. Now demo code does not crash but unfortunately also does not update the plot. The previous "Crashing Case" has to behave the same way like "Working Case" behaved: when you keep clicking on radiobuttons the appropriate plots have to appear or disappear. Does it work on your computer exactly this way?

[PaulLaidler]

Dan

Is it possible to share your code more widely so that others might get involved in trying to work out how to fix this?