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 

Win7/OpenGL/Listview/Nvidia crash
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


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

PostPosted: Wed Apr 09, 2014 9:47 pm    Post subject: Reply with quote

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



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

PostPosted: Thu Apr 10, 2014 3:07 am    Post subject: Reply with quote

When did you fix that, Paul? I clearly missed this fix. All works now, including multithreading, kudos and thanks to you.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Apr 10, 2014 8:29 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Thu Apr 10, 2014 9:15 am    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



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

PostPosted: Thu Apr 10, 2014 4:03 pm    Post subject: Reply with quote

Sebastian, Post the example demonstrating what specifically this fix negatively impacts.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Apr 11, 2014 8:15 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Fri Apr 11, 2014 11:20 am    Post subject: Re: Reply with quote

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


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

PostPosted: Fri Apr 11, 2014 7:10 pm    Post subject: Reply with quote

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



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

PostPosted: Fri Apr 11, 2014 10:10 pm    Post subject: Reply with quote

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


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

PostPosted: Sat Apr 12, 2014 11:23 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Mon Apr 14, 2014 10:16 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Tue Apr 15, 2014 1:54 pm    Post subject: Re: Reply with quote

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
View user's profile Send private message
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Thu Mar 05, 2015 11:28 am    Post subject: Re: Reply with quote

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


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

PostPosted: Thu Mar 05, 2015 4:53 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Fri Mar 06, 2015 7:57 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
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