Updating drivers to 361.18 causes Aspyr’s Linux port of Star Wars: Knights of the Old Republic II to segfault on startup.
There is no error, except for the following in syslog:
Jan 16 19:39:42 clevo kernel: [ 2071.032543] KOTOR2: segfault at edc ip 00000000f6ce86f4 sp 00000000f0edff6c error 4 in libGLdispatch.so.0[f6ca9000+7e000]
Backleveling to the 358 drivers causes the game to work properly again. Most other games seem to work fine with the 361.18 drivers.
This is under Ubuntu 16.04 w/KDE. Laptop chipset is GK104M [GeForce GTX 670MX] (rev a1).
Update: This also occurs with Civ5.
Jan 16 20:41:24 clevo kernel: [ 5776.194868] Civ5XP: segfault at edc ip 00000000f6bef6f4 sp 00000000f17eb86c error 4 in libGLdispatch.so.0[f6bb0000+7e000]
These are both Aspyr ports, so there’s a good chance they’ve got some common code triggering the issue. I’ve tried at least one other Aspyr port (maybe Borderlands 2, I don’t recall) that works fine. nvidia-bug-report.log.gz (250 KB)
Civilization5 (and presumably KOTOR2 as well) calls glGetInteger in a thread where no context is (or was ever) made current. This is undefined behavior and therefore an application bug.
The introduction of vendor-neutral dispatch in the NVIDIA driver (libglvnd) in r361 beta has changed how the driver responds to this situation: it used to tolerate this undefined behavior, but now crashes. This is legal on the part of the driver, although clearly not optimal.
We are working on a fix in the driver, such that the official r361 release does not effectively break games that used to be working. However, the games should be fixed.
Your feedback on bugs in our beta releases is greatly appreciated. Until the bug is fixed, I would advise downgrading to r358 (but it is affected by an unrelated crash in Steam) or r352.
Would it be possible to have the driver complain about the fixups it applies to technically illegal use of the GL API, so that we can report these things to the game developers and avoid it in our own code as well? Or have a compatibility-disabling envvar to have the driver conform more strictly to the GL API?
Whenever possible, we do of course report errors, through KHR_debug or other means (such as shader compiler error messages), and sometimes provide an application profile and environment variable to revert to the previous behavior. (In this particular case, an environment variable will not be possible either.)