Crash on XServer-side glx module with nvidia drivers

XServer:

X.Org X Server 1.16.1
Release Date: 2014-09-21

backtrace:

#0  0x00007f86d8efdbf6 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#1  0x00007f86d55d7037 in ?? () from /usr/lib/xorg/modules/drivers/nvidia_drv.so
#2  0x00007f86d55d794c in ?? () from /usr/lib/xorg/modules/drivers/nvidia_drv.so
#3  0x00000000004376d7 in ?? ()
#4  0x000000000043b866 in ?? ()
#5  0x00007f86db073040 in __libc_start_main () from /usr/lib/libc.so.6
#6  0x0000000000425d0e in _start ()

This happens when restarting Enlightenment (left click on desktop -> Enlightenment -> Restart) when compositor is using GL for compositing. The restart itself is an exec() of the same binary from itself. Using git version of efl, elementary, evas_generic_loaders and enlightenment from: http://git.enlightenment.org. Recent fixes for ARGB visual handling in efl have now triggered this server-side bug (this fixed up GLX and EGL/GLES visual selection since nvidia drivers, unlike mesa, are particularly picky about visuals used - relevant commit: http://git.enlightenment.org/core/efl.git/commit/?id=696346c4673f2d88b562c02750277a5fb3e41f9e).

nvidia-bug-report.log.gz (80.3 KB)

Attached nvidia-bug-report.log.gz

it seems calling glXMakeContextCurrent(disp, 0, context); where disp is valid and context is valid (to clear out any refs to a glxwinindow in the context that’s about to be destroyed) causes the xserver side itself to crash. while this isn’t perfectly valid client code (though to be honest it’s ambiguous according to the docs), this shouldn’t cause server crashes. :)