forums.silverfrost.com

[DanRRight]

When you run some subroutine for the second time which has ALLOCATE inside and the subroutine trying to allocate already allocated array.

I think this is wrong diagnostics message. Specifically if there are no POINTERs used


Another similar error 421: Reference through dangling Fortran pointer. That i do not know why happened today after normal work with no reason at all. On this piece of code:

[JohnCampbell]

Dan,

The following code could run faster and clarify some integer division.
Is magnFactor real ?

[DanRRight]

John,
In 2020th to program like this should be considered as a crime.
The compiler is doing optimizations like that (taking our repetitive constants) automatically.

The issue with magnifier is not related to allocation. Program works but just sometimes crashes with this strange bug report, mostly when i do debug. This happens for 20 years and in 20 years no one reported that kind of bug or provided simple demo. I sometimes can not shorten my programs to isolate the bug without much of efforts.

The magnification code works nicely, looks beautiful, people do not believe that this is made in Fortran and done in days. I see similar efforts in GitHub lasting for 10 years with 50 bug fixes per year. The exact magnification factor probably not like i claim that, i do not remember the reasons for all my adjustments, but it does not matter.

[JohnCampbell]

Dan,

You did not show how arrays MagnifierArr and ImageArr are defined.

My minimum requirement is as arguments would be:
integer MagnifierArr(3, ixsizMag,iysizMag), ImageArr(3,hres,vres)
This is on the basis of the do range and max/min

Could there be a call path where they are not allocated ?
or hres and vres are corrupt; perhaps check the array dimensions for sensibility?
Perhaps use ALLOCATED, which would need appropriate declarations.

I also suggested that swapping do ix and do iy would help, which I am not sure is typically optimised.

Is this code run as 32-bit or 64-bit, as 32-bit can have ALLOCATE errors ?

[DanRRight]

I think the issue with the second "pointer" error report in my magnifier code is related to Clearwin when it handles a lot of load in full mouse input mode. You move mouse and 10s of calls takes place handling mouse and the entire GUI by updating variables, switching graphics windows, detecting mouse positions, copying data from array to magnifying array, displaying magnifier image in real time etc etc etc. This is why this crash happens only in /DEBUG /UNDEF mode where some operations could be delayed by mere microseconds and could not have the object which is already autodeleted or something like that. "Dangling pointer" message when there are no user defined pointers just confuses people

[JohnCampbell]

My solution for the repeated mouse interupts has been to only update after a minimum movement distance.

Alternatively, you could have a status variable, say "magnify_in_progress" and either ignore the move or set a status that further updates are required.

As the mouse interupt is effectively "another thread", could this imply that :
* if ix_mouse and iy_mouse are global variables, that they could be modified by the subsequent interupts.
* if another magnify operation commences, redoing the ALLOCATE, potentially destroying the active magnify operation

I think the "magnify_in_progress" approach could be a help for the pointer error report, as multiple threads could cause deallocate. You would need to be careful with the timing.
(All local variables would need to be dynamic on the stack.)

[DanRRight]

First, there is no allocate during operation of magnifier. ALLOCATE is only done at the start of the program. ALOCATE diagnostics problem is for the first my example out of two mentioned initially in the post, sorry about possible confusion

Yes, I have the protecting mechanism for the magnifier (which i recommend to everyone) which prevents any operations till the previous ones are finished. For that i have the global variable which casts the message "I am busy" till the last executable command in the callback function when its changes to "i am free". Experience also tells that such callback function is good to name "integer recursive function", instead just "integer function"

But again, my message was not about all that but to inform Silverfrost about hiccup of its diagnostics by mentioning pointers where there is no pointers. Possibly it does not even really hiccups but all error diagnostics messages are definitely way too laconic by not mentioning more options as if there is limited memory on computer ferromagnetic array and floppy disk, almost no paper left on the console printer or is too little space on users black and white CGA monitors. Getting such error messages makes you totally miserable in the dark space of 710 000 lines of source code.