With unichrome dri, glxinfo segfaults with the following stack trace: 0xb778766e in viaXMesaWindowMoved (vmesa=0x8056220) at via_context.c:745 745 switch (vmesa->glCtx->DrawBuffer->_ColorDrawBufferMask[0]) { (gdb) bt #0 0xb778766e in viaXMesaWindowMoved (vmesa=0x8056220) at via_context.c:745 #1 0xb7787a6b in viaGetLock (vmesa=0x8056220, flags=0) at via_context.c:913 #2 0xb778bd09 in viaWaitIdle (vmesa=0x8056220, light=0 '\0') at via_ioctl.c:455 #3 0xb7787efd in viaDestroyContext (driContextPriv=0x80540e8) at via_context.c:701 #4 0xb7783837 in driDestroyContext (dpy=0x804e008, scrn=0, contextPrivate=0x80540e8) at ../common/dri_util.c:753 #5 0xb7dfbeea in DestroyContext (dpy=0x804e008, gc=0x80560e0) at glxcmds.c:472 #6 0x0804a0ae in main (argc=-1074695228, argv=0x0) at glxinfo.c:495 #7 0xb7c95f90 in __libc_start_main () from /lib/i686/libc.so.6 #8 0x08048bc1 in _start () vmesa->glCtx->DrawBuffer is NULL in viaXMesaWindowMoved()
Created attachment 11207 [details] [review] fix NULL pointer dereference in viaXMesaWindowMoved The attached patch fixes the glxinfo segfault, but I'm not sure it's the correct way to proceed.
I think that if nothing was sent to the hardware there is no reason to wait for idle in viaDestroyContext but let me check if that is the case. There is a similar problem when driDrawable is NULL.
This is a pretty old bug now, but we do still carry it on our Mesa packages... Is there any chance it can be committed upstream. Are there more appropriate QA contacts at mesa these days?
Closing as wontfix, since unichrome (DRI1) has been dropped.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.