Bug 1397183

Bugzilla won't let me complete this report, but will allow Addl Comments, so here goes:

The FlightGear simulator no longer will run on Fedora 24 as a normal
user, but will run as root.

That's unsanitary, and I won't permit it.

I also discovered that glxinfo and glxgears also fail under F24,
and not F23.

I still have three recent F24 kernels and three less recent F23
kernels in a separate root partition.
fgfs (and glxinfo and glxgears) run correctly on all F23 systems
and none of the F24's.

What I believe to be the relevant packages are perfectly symmetric:

[dad@datair ~/f23]
$ grep -i flight rpms.3
FlightGear-3.4.0-6.fc23.x86_64
FlightGear-Atlas-0.5.0-0.13.cvs20141002.fc23.x86_64
FlightGear-data-3.4.0-3.fc23.noarch
[dad@datair ~/f23]
$ grep -i nvidia rpms.3
akmod-nvidia-304xx-304.131-3.fc23.x86_64
kmod-nvidia-304xx-4.5.7-200.fc23.x86_64-304.131-3.fc23.x86_64
kmod-nvidia-304xx-4.5.7-202.fc23.x86_64-304.131-3.fc23.x86_64
kmod-nvidia-304xx-4.6.4-201.fc23.x86_64-304.131-3.fc23.x86_64
xorg-x11-drv-nvidia-304xx-304.131-1.fc23.x86_64
xorg-x11-drv-nvidia-304xx-libs-304.131-1.fc23.x86_64
[dad@datair ~/f23]
$ grep -i glx rpms.3
glx-utils-8.2.0-4.fc23.x86_64

[dad@datair ~/f24]
$ grep -i flight rpms.2
FlightGear-2016.1.2-2.fc24.x86_64
FlightGear-Atlas-0.5.0-0.23.cvs20141002.fc24.x86_64
FlightGear-data-2016.1.2-1.fc24.noarch
[dad@datair ~/f24]
$ grep -i nvidia rpms.2
akmod-nvidia-304xx-304.132-1.fc24.x86_64
kmod-nvidia-304xx-4.8.4-200.fc24.x86_64-304.132-1.fc24.x86_64
kmod-nvidia-304xx-4.8.6-201.fc24.x86_64-304.132-1.fc24.x86_64
kmod-nvidia-304xx-4.8.7-200.fc24.x86_64-304.132-1.fc24.x86_64
xorg-x11-drv-nvidia-304xx-304.132-1.fc24.x86_64
xorg-x11-drv-nvidia-304xx-libs-304.132-1.fc24.x86_64
[dad@datair ~/f24]
$ grep -i glx rpms.2
glx-utils-8.3.0-3.fc24.x86_64


On F24, running fgfs as dad (me) fails with these error messages:

$ fgfs
   ...
Error: Unable to create OpenGL graphics context.

getDefaultWindow: failed to create GraphicsContext
Error: Unable to create OpenGL graphics context.

getDefaultWindow: failed to create GraphicsContext
   ...


That's puzzling.
After some further groping in the dark, I discovered that both
glxinfo and glxgears also fail to run as regular user but run correctly
as root.  That seems closer to the real problem, I think.
I strongly suspect the fgfs program is entirely blameless.

Here's the output of glxinfo, run by dad:  (glxgears is similar)

$ glxinfo
name of display: :0
X Error of failed request:  BadValue (integer parameter out of range
for operation)
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  Value in failed request:  0x0
  Serial number of failed request:  87
  Current serial number in output stream:  88


So, as a WAG, I'll ascribe this bug to this package:
    glx-utils-8.3.0-3.fc24.x86_64

Unfortunately, I have no real clue why these failures are occurring.

Your problem seems related to the way your commands interact with the nvidia driver. To debug such cases, you can try to run glxinfo under the strace program to check if glxinfo can access successfully to the nvidia device with /dev/nvidia*

If it works as root and not as a regular user, bad permission on these files may be very possible (selinux related ?).

Created attachment 1231319 [details]
strace glxinfo   (as dad)

strace of failed glxinfo

Created attachment 1231320 [details]
strace glxinfo  (as root)

Fabrice Bellet, thank you for your helpful suggestions.  I apologize for my delayed response.

1) selinux is disabled:
# sestatus
SELinux status:                 disabled

2)  The nvidia device files are fully read/write:
# ll /dev/nvid*
crw-rw-rw- 1 root root 195,   0 Dec  5 16:03 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Dec  5 16:03 /dev/nvidiactl

3)  I ran  
$ strace glxinfo 2>&1 | tee glxinfo.str.dad
and 
# strace glxinfo 2>&1 | tee glxinfo.str.root

I tried to comprehend the dad case, which fails, but cannot detect the problem.  Although I can see the beginning of the failure messages, I cannot perceive the triggering cause.  That is, there are no failures to open specific files or nvidia devices that I can see that would trigger the "BadValue (integer parameter out of range for operation)" message.

I used  comm  to compare the two files.  They are similar up to the point of failure, but again, I cannot detect what fails.
(There are an awful lot of  getpid()'s  in both files.  One would think one would be enough.)

Perhaps you can see the problem.  I have attached both files.  Sorry for the size.

This bug is dead, or maybe never existed.

On my troublesome machine, I did a fresh install of Fedora 25 from the Live Xfce iso.  After installing each batch of new packages, I tested  glxinfo  as dad and verified it worked correctly, saving nvidia for last.  After installing nvidia-304xx, but before rebooting to use it, glxinfo failed!  So I removed nvidia-304xx and glxinfo worked again.

After some thought (!) I reinstalled nvidia-304xx, and this time rebooted.
Eureka!  glxinfo worked - as dad.  So does fgfs, the FlightGear simulator.

Based on the similarity of the error messages with nvidia installed but not being used, it just might be the case that my previous experience is now explained.  But of course, I could never admit such idiocy.

Thanks, closing the bug report.