Win7/OpenGL/Listview/Nvidia crash

Hello,

strange combination of features that leads to a crash, it only happens on nVidia graphics cards (several have been tested, various driver versions) and never on ATI/AMD cards. The only feature that relates to graphics cards is the OpenGL window, though that is just a dummy in the test case (so there may be a problem related to the OpenGL initialization in salflibdll-internal routines). It happens at least with compiler version 6.00 and reportedly 6.10 as well.

The crash happens if an underflow occurs in a callback function of a list view (the 1.e-281.e-29 results in 0.0 for real4 where underflow is signaled but should be ignored as of default ftn95 settings). It looks like the underflow handler crashes the application.

To reproduce the problem use the sources posted below, compile with 'ftn95 lvtest.f95 /link', debug settings enabled if you wish to trace the callback code. Running the application, then click on the second entry and the application will crash (again this is Win7+nVidia only as of our testings).

An additional strange quirk is that it seems to behave different if the listview content strings are defined as character(len=12) instead of len=* but that may or may not be a red herring.

Sources for lvtest.f95:

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

Thanks!

Sebastian,

I tried your example ( on an XPx64 machine without an nVidia card)

I compiled with Ver 5.50.0 /check /link and ran it in sdbg; selected Data2 and stepped through callback. F3 underflows to zero, with no message.

I must admit I prefer len=12 to len=*

John

It works for me as well both on an XP/nVidia machine, as well as a Win7/ATI machine.

This seems to be the source for a lot of crashes lately, nVidia cards are much more widespread and close-to-zero values may occur any time when interacting with external data (it even happens often with values far away from denormals as can be seen in the example).

Anybody looking into this? If you need more information or additional testing please let me know.

It doesn't fail for me on my Win 7 x64 nVidia PC. Is it driver dependent?

No it isn't, I've tried it on several PCs (mostly Win7/64bit) with different graphics cards.

Examples I've just checked out again with driver version information: GeForce 460 v266.35 GeForce 285 with lots of different drivers ranging from 197.45hql to 270.51beta.

All exhibit the same problem, clicking on the second entry and then closing the application leads to a program crash.

Sebastian - do you see Exception 0xc000041d?

If running it the regular way it triggers a 'does not work any longer' message of Win7 without further information. If it's run under sdbg it'll indeed halt at Unknown/user32.dll with Exception 0xc000041d.

If the callback handler is traced in sdbg I see the f3 = f1*f2 (which causes the underflow) to never return.

Thanks for looking into this!

It occurs on several other PCs as well including GTX 460M (==mobile) nVida cards. Any progress on this?

Still looking at it. The example does work if you mask the underflow exception - which you can do by using this command prompt command:

set salfenvar=mask_underflow

Not happy about that as a solution though.

Any news on this? I've converted a part of the code to crop small numbers to zero but this can not be done in many other places since we would lose by far too much of the precision.

Did setting the environment variable work for you?

Yes but that's not something I can automatedly do for the main application, nor do I know what effects this would have.

This is still not fixed. Reported 3 years ago.

I've just tried on a bunch of old and new PCs, it does not work on any nVidia (consumer) graphics card PC (Drivers may be old or new it has no effect on the crash) whereas it does work on any AMD graphics card as well as an nVidia QUADRO card in an old XP system.

Currently smallest program to reproduce the crash:

program test 
   implicit none
   integer :: iw, sel
   character(len=*),dimension(2), parameter :: wlist=(/'e1','e2'/) 
   external testcb
   iw = winio@ ('%og[double]',300,200)
   sel = 1
   iw = winio@ ('%^lb',wlist,2,sel,testcb)
end program 
integer*4 function testcb()
   implicit none
   real*4 :: f1, f2, f3
   testcb = 2
   f1 = 1.e-28
   f2 = 1.e-29
   f3 = f1*f2
end function

where you can compile it with basically arbitrary flags. Running it, you click away the first window (the OpenGL one) and then select the other entry on the list box to Trigger the callback function. that part crashes when the denormal is (tried to be) stored in f3.

Thanks.

Sebastian, This code freezes with Nvidia GTX770, driver 335.23 (release 3/10/2014), Windows 8.1, Intel processor

Underflows is one of the damnest hidden problems sometimes. Years ago I had it sporadically crashing the code even with the standard Fortran source where i calculated exp(-X) with X becoming large. I do not see that anymore though, or may be i restricted the X range, i forgot. I posted here about that (you can find by searching this forum by keyword 'underflow' and by my username).

BUT.

We still experienced deadly bites of underflow recently. I posted demonstrating example for that, it is in the last page about multhithreading with NET

https://forums.silverfrost.com/Forum/Topic/2238&start=45

Same flaw still bites the nice parallel method Jalih developed which pushed me to abandon it because when crash happen it is not possible to find where (since the debugging did not work with multithreading). My code uses a lot of exponents and some values permanently go under. I made all needed restrictions to not allow underflow but it squeezed finally somewhere else and i couldn't find where in days.

I have not yet try and investigate in detail if all this will crash and not allow to debug the parallel method developed by Paul recently:

https://forums.silverfrost.com/Forum/Topic/2239

Try calling mask_underflow@...

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

When did you fix that, Paul? I clearly missed this fix. All works now, including multithreading, kudos and thanks to you.

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.

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.

Sebastian, Post the example demonstrating what specifically this fix negatively impacts.