View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Wed Apr 09, 2014 9:47 pm Post subject: |
|
|
Try calling mask_underflow@...
Code: | program test
implicit none
integer :: iw, sel
character(len=*),dimension(2), parameter :: wlist=(/'e1','e2'/)
integer,external::testcb
call mask_underflow@()
iw = winio@('%og[double]&',300,200)
sel = 1
iw = winio@('%^ls',wlist,2,sel,testcb)
end program
integer*4 function testcb()
implicit none
real*4 :: f1, f2, f3
f1 = 1.e-28
f2 = 1.e-29
f3 = f1*f2
testcb = 2
end function |
|
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2818 Location: South Pole, Antarctica
|
Posted: Thu Apr 10, 2014 3:07 am Post subject: |
|
|
When did you fix that, Paul? I clearly missed this fix. All works now, including multithreading, kudos and thanks to you. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Thu Apr 10, 2014 8:29 am Post subject: |
|
|
This routine has been available (and documented) since the early days of FTN95 and may also have featured in FTN77. I have to admit that I am not familiar with it. It can be found in the help file by searching for its name or for "denormal". It is possible that, for some compilers, this masked state is ON by default. |
|
Back to top |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Thu Apr 10, 2014 9:15 am Post subject: |
|
|
This is not a fix, and especially not anything that I'd advise to set in a well-tested code since it significantly changes the behaviour of a lot of floating point operations. Simple example is that comparison of a float variable with const-zero may behave differently than before.
Any other idea? Why is it related to creating an OpenGL-window? Thanks. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2818 Location: South Pole, Antarctica
|
Posted: Thu Apr 10, 2014 4:03 pm Post subject: |
|
|
Sebastian, Post the example demonstrating what specifically this fix negatively impacts. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Fri Apr 11, 2014 8:15 am Post subject: |
|
|
First of all, it is quite likely that Sebastian and Dan are having to deal with different issues so what might satisfy one may not satisfy the other.
Second, I have no real understanding of what is going wrong in either case.
However, using masked underflow should not, in my opinion, significantly affect the numerical results. If it does then this suggests that the numerical calculation is unstable (i.e. significantly affected by round-off error).
For 32 bit REALs, the smallest exponent is 1E-38 for unmasked underflow and 1E-46 for masked underflow. If you test a computed REAL z against zero then in one case you will be testing abs(z) < 1E-38 and abs(z) < 1E-46 in the other. Clearly this is not good programming practice and the compiler warns against this. Not only will the outcome depend on the masking but (more importantly) on the KIND of the REAL.
On another track, if using masked underflow does not help, then I have one other suggestion to try. It is based on the possibility that some third party computation (from OpenGL and/or the graphics card) is leaving the coprocessor in an unclean state. The following code, placed before the crash point, will reset the coprocessor...
Code: | CODE
fclex;
finit;
fround;
EDOC
|
Again, this is just shooting in the dark since I don't have anything of substance to work on, not being able to reproduce the issues in question. |
|
Back to top |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Fri Apr 11, 2014 11:20 am Post subject: Re: |
|
|
DanRRight wrote: | Sebastian, Post the example demonstrating what specifically this fix negatively impacts. |
Anything that expects floats to get zero at a boundary (see fpu smallest sizes for non-denormals) will behave differently when reaching those numbers. If this is a problem for your code depends on whether you can exclude somebody was coding with these boundaries in mind or not.
PaulLaidler wrote: | Second, I have no real understanding of what is going wrong in either case.
|
So you cannot reproduce the issue? Get any win7-PC with a nVidia consumer graphics card, run the program, click on the 2nd window's list box entries and see the app crash.
PaulLaidler wrote: | If it does then this suggests that the numerical calculation is unstable (i.e. significantly affected by round-off error). |
Any numerical calculation, any gui-to-data conversion, anything that expects numbers to pass a "equal to zero" test with a non-denormal boundary will not work as it did before. This is unacceptable.
PaulLaidler wrote: | The following code, placed before the crash point, will reset the coprocessor...
|
This is dangerous code (the finit leaves the fpu in a state that may be different than what the compiler knows it should be). It does not fix the problem anyways, also I've already debugged the respective routines and the fpu state (cw and sw) are not touched by the graphics card drivers. The problem is most likely in some routines that deal with exception handling which are affected by the clearwin %og code.
I again may Point out that the callback works fine if it is called from a menu entry, from a button klick, but NOT (as in the sample) from a listview callback. I was hoping that this alone would lead some insight into what's going on in this case...
Thanks for any help! |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Fri Apr 11, 2014 7:10 pm Post subject: |
|
|
I have reproduced a failure when using %ls under Windows 8.
I am hopeful that this is the same issue as both of the issued raised here and that an "acceptable" fix will be available shortly. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2818 Location: South Pole, Antarctica
|
Posted: Fri Apr 11, 2014 10:10 pm Post subject: |
|
|
Paul, Here is one more example when underflow crashes the code. This is your demo code for introduced recently mulththreading with FTN95:
http://forums.silverfrost.com/viewtopic.php?t=2534
I added to it only two lines which with time cause the crash as soon as the value of exponential function hits the underflow limit. You can play with the value 12.5 to see that crash started earlier or not happen at all
Adding call mask_underflow@() fixes this crashing problem (add the commented line)
Code: |
module threadMod
c_external start_thread@ '__start_thread' (REF,REF):integer*4
c_external wait_for_thread@ '__wait_for_thread' (VAL)
c_external lock@ '__lock' (VAL)
c_external unlock@ '__unlock' (VAL)
integer,parameter::IO_LOCK = 42 !Any value. Your choice
contains
subroutine threadFunc(count)
integer count,start
if(count < 0) return !Illustrates an abort
start = count
do while(count > 0)
call sleep1@(1.0)
call lock@(IO_LOCK)
print*, -12.5*count !!!! added line
A = exp(-12.5*count) !!!! added line
print*, "threadFunc ", start, count
call unlock@(IO_LOCK)
count = count - 1
end do
end subroutine threadFunc
end threadMod
program Threads
use threadMod
integer hThread(3)
!!! call mask_underflow@() ! fixes underflow
hThread(1) = start_thread@(threadFunc, 6) !Run for 6 seconds
hThread(2) = start_thread@(threadFunc, 3) !Run for 3 seconds
hThread(3) = start_thread@(threadFunc, 7) !Run for 7 seconds
call wait_for_thread@(hThread(2))
call wait_for_thread@(0)
end
|
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Sat Apr 12, 2014 11:23 am Post subject: |
|
|
Dan
This must be an unrelated issue.
I don't know why masking fixes the problem.
For the moment I will simply log this for investigation. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Mon Apr 14, 2014 10:16 am Post subject: |
|
|
I have uploaded a new version of salflibc.dll to www.silverfrost.com/beta/salflibc.exe
This provides a potential fix for the reported failure of %ls under Windows 7.
Sebastian: Does this fix the original issue on this thread? |
|
Back to top |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Tue Apr 15, 2014 1:54 pm Post subject: Re: |
|
|
PaulLaidler wrote: | This provides a potential fix for the reported failure of %ls under Windows 7.
Sebastian: Does this fix the original issue on this thread? |
Yes it does, thanks for figuring this out!
Is the DLL safe to use in production code (v7.00 ftn95+the posted DLL)? I'd like to give it some testing with the application where the bug originally occurred.
Thanks again. |
|
Back to top |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Thu Mar 05, 2015 11:28 am Post subject: Re: |
|
|
PaulLaidler wrote: | This provides a potential fix for the reported failure of %ls under Windows 7. |
The fix seems to be specific to %ls, the following program (note it uses a `ls-style listbox) crashes.
Code: |
winapp
program listbox
implicit none
external callback
integer :: v, i
character (len=*), dimension(3), parameter ::lvdata = &
(/'|Data1 |', '|Data2 |', '|Data3 |'/)
v = 1
i=winio@ ('%og&', 100,100)
i=winio@('%^`20.5ls',lvdata, 3, v, callback)
end program listbox
integer function callback()
real :: f1,f2,f3
callback = 2
f1 = 1.e-28
f2 = 1.e-29
f3 = f1*f2
f3 = f3*f3
end function
|
Also it seems that callbacks on radio buttons can trigger the crash in a similar way, any idea if the fix is somehow "generally" applicable?
Thanks! |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Thu Mar 05, 2015 4:53 pm Post subject: |
|
|
I currently am running under 64 bit Windows 8.1 with an nVidia Geforce graphics card.
If you have a test program that crashes in this environment then hopefully I can make progress. |
|
Back to top |
|
|
Sebastian
Joined: 20 Feb 2008 Posts: 177
|
Posted: Fri Mar 06, 2015 7:57 am Post subject: |
|
|
The code I've posted is the test program, compile with no special flags. I only have Win7 as platform available for testing though.
On trying to choose a different list box entry, the test application hangs/crashes.
Thanks! |
|
Back to top |
|
|
|