[Mesa-dev] [PATCH] dri2GetGlxDrawableFromXDrawableId may return NULL

Niels Ole Salscheider niels_ole at salscheider-online.de
Fri Jul 30 02:47:42 PDT 2010


> > Since dri2GetGlxDrawableFromXDrawableId may return NULL we
> > should only dereference the returned pointer if it is not NULL.
> It shouldn't return NULL... when does this happen? During shutdown?
> We only get the DRI2 events for drawables we've created a DRI2
> drawable for, which means there should be a __GLXDRIdrawable in the
> hash.

It happens (randomly?) when I try to activate or change kwin's (4.4.95) 
desktop effects.

This is the first backtrace I posted on IRC:

Application: KWin (kwin), signal: Segmentation fault
[KCrash Handler]
#6  0x00007fba52383d49 in dri2InvalidateBuffers () from 
#7  0x00007fba52383ead in dri2SwapBuffers () from //usr/lib64/opengl/xorg-
#8  0x00007fba56f78c85 in KWin::SceneOpenGL::flushBuffer(int, QRegion) () from 
#9  0x00007fba56f79c06 in KWin::SceneOpenGL::paint(QRegion, 
QList<KWin::Toplevel*>) () from /usr/lib/libkdeinit4_kwin.so
#10 0x00007fba56f6469c in KWin::Workspace::performCompositing() () from 
#11 0x00007fba56ee87c2 in KWin::Workspace::qt_metacall(QMetaObject::Call, int, 
void**) () from /usr/lib/libkdeinit4_kwin.so
#12 0x00007fba53ae7006 in QMetaObject::activate(QObject*, QMetaObject const*, 
int, void**) () from /usr/lib64/qt4/libQtCore.so.4
#13 0x00007fba53ae38b6 in QObject::event(QEvent*) () from 
#14 0x00007fba546fcc0c in QApplicationPrivate::notify_helper(QObject*, 
QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#15 0x00007fba5470320b in QApplication::notify(QObject*, QEvent*) () from 
#16 0x00007fba5566aee8 in KApplication::notify(QObject*, QEvent*) () from 
#17 0x00007fba53ad3d6b in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib64/qt4/libQtCore.so.4
#18 0x00007fba53b008ba in QTimerInfoList::activateTimers() () from 
#19 0x00007fba53b00acb in 
QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () 
from /usr/lib64/qt4/libQtCore.so.4
#20 0x00007fba547ac595 in 
QEventDispatcherX11::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () 
from /usr/lib64/qt4/libQtGui.so.4
#21 0x00007fba53ad2692 in 
QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from 
#22 0x00007fba53ad2a5d in 
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from 
#23 0x00007fba53ad769b in QCoreApplication::exec() () from 
#24 0x00007fba56f0341b in kdemain () from /usr/lib/libkdeinit4_kwin.so
#25 0x00007fba50a22bbd in __libc_start_main () from /lib/libc.so.6
#26 0x0000000000400969 in _start ()

dri2_glx.c, line 508ff says the following:

/* Old servers don't send invalidate events */
if (!pdp->invalidateAvailable)
   dri2InvalidateBuffers(dpyPriv->dpy, pdraw->drawable);

So dri2InvalidateBuffers should only be called if the server is "old" - I am 
using xorg-server 1.8.2, is that "old"? Maybe the server sends invalidate 
events and dri2InvalidateBuffers is called so that it cannot find the drawable 

Unfortunately I am not at home until Wednesday so that I cannot debug it 
further until then.

> As for the bind_tex_image, does KWin create a glx drawable and
> then use the X window XID for tfp?  These things shouldn't happen so I
> don't just want to slap a NULL check on them without understanding how
> it happens.

I have to admit that I do not know much about mesa's or kwin's internals. I 
only noticed that there are some NULL pointer checks for GetGLXDRIDrawable and 
thought that this was the way to go.
In dri2_bind_tex_image there is already a NULL-pointer check in line 662 (I do 
not know why it is there and unfortunately I do not have a backtrace at the 
moment). But this check is useless since the returned drawable is already 
dereferenced in line 660.

Kind regards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100730/424dc86e/attachment-0001.pgp>

More information about the mesa-dev mailing list