Array access in callback crashes App (OpenGL-related)

Hello, the following application hangs when assigning an array element (on my system indices above 1100 hang, below 1000 it works fine). Characteristics of the program: OpenGL-window (on nVidia it hangs, ATI and possibly non-gamer nVidia cards seem to be fine), virtual common is used (otherwise it works flawless) Steps to reproduce: click on menu item, click on SetVal button, application hangs (noted by not being able to use the Close button which otherwise works) Tested on several systems, latest ftn95 including the beta salflib.

Source (tester.f95):

module DataMod
  real*4, dimension(5000) :: tmp
end module DataMod

program tester
external MenuItem
integer*4 :: iw, MenuItem
  iw=winio@('%og&',640,480)
  iw=winio@('%mn[MenuItem]',MenuItem)
end

integer*4 function MenuItem()
implicit none
integer*4 :: iw
external  :: SetVal, CloseWin
integer*4 :: SetVal, CloseWin
  MenuItem = 2
  iw=winio@('%^6bt[SetVal] &',SetVal)
  iw=winio@('%^6bt[Close]',CloseWin)
end

integer*4 function SetVal()
use DataMod
  SetVal = 2
  tmp(1:5000) = 0.0 ! application hangs here
  tmp(1111) = 0.0   ! same effect
end

integer*4 function CloseWin()
  CloseWin = 0
end

Linkfile:

lo tester.obj
vc
file tester.exe

Thanks!

I can not get this program to fail. I have tried it on two machines. One has NVidia GeForce GT 750M. The other display adapter is described as Mobile Intel 4 Series...

Hm I don't have any laptops available for testing at the moment, yet all non-mobile nVidia graphics cards (excluding Quadro) could reproduce the hang. Did you use the linkfile, or any other means of assuring that virtual common is used?

All works fine here too. Laptop (Intel/ATI switceable graphics) Win7 and Nvidia GTX770 desktop Win8

I did omit to use virtual common. On retesting it does fail.

The failure depends on using VC. It appears to be unrelated to %og and unrelated to the display driver. Using a common block instead of a module does not appear to help.

Try USEing the module in the main program to see if this fixes it.

I will log this for investigation. My current tests are under Windows 7 and it would help to know if the same problem occurs under Windows XP.

As of our testings this is a regression since XP (though it does not occur on all systems), yet we don't have win8 available. All XP installations can run the application without problems.

USEing the module in the main program does not change anything.

On my tests it is necessary that there is an %og window, even if it may not directly be related.

Thanks for looking into this!

It may be worth reviewing the advantages of using VC (search for 'virtual common' in the help file). If this regression depends on the operating system then it may be very difficult to fix.

In the mean time, any information about the behaviour for particular operating systems (32 bit or 64 bit) would be useful.

I also missed VC which i used a lot before but not anymore.

And yes code hangs with VC with NVIDIA (on Win8 64bit OS even with all the compatibility settings with XP )

It works on Win7 64bit OS laptop with ATI but hangs when laptop switches on battery power and uses power saving Intel graphics

This is not fixed in 7.10 and the differing behaviour as described in the original posting (works on ATI, fails on most nVidia gamer graphics Cards; XP is unaffected, buggy under win7+) has been verified on several PCs, workstations and mobile computers. Any Progress? Thanks!

Will the code work without VC? I used this switch a lot couple decades ago but then later on found that it has no effect when the RAM sizes on PCs became larger then 2GB. In principle this switch will be potentially very useful again in the future if FTN95 will be finally 64bit (hope it will) which will allow user to run the codes allocating sparce matrices up to 256 TB which is the current OS/hardware temporal limit but I think its usefullness is gone with todays addressable memory size of 32bit compiler. Am I wrong?

Yes it works when disabling VC. This is not relevant to me though since the bug may just be hidden by the changed Memory layout or whatever, but that's up to the developers to check out. I don't want to hit this bug randomly in a non-VC application and debug it again, or even worse have a customer experience it in hard to reproduce circumstances.