Bug 29370

Summary: Crash when trying to enable 3D with KMS/DRI2
Product: Mesa Reporter: Nikos Chantziaras <realnc>
Component: GLXAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact:
Severity: critical    
Priority: medium    
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Nikos Chantziaras 2010-08-03 00:29:19 UTC
KWin crashes when trying to activate OpenGL desktop effects.  I do not know if bug 29181 is related; could be.

I'm on Mesa git master, kernel 2.6.35 using Radeon KMS, xorg-server 1.8.2, xf86-video-ati git master, Radeon HD4870.

This is the backtrace:

Application: KWin (kwin), signal: Segmentation fault
[KCrash Handler]
#6  dri2InvalidateBuffers (dpy=<value optimized out>, drawable=<value optimized out>) at dri2_glx.c:643
#7  0x0000003008c5106d in dri2SwapBuffers (pdraw=<value optimized out>, target_msc=<value optimized out>, divisor=<value optimized out>, remainder=<value optimized out>) at dri2_glx.c:510
#8  0x000000307f6c9dc7 in KWin::SceneOpenGL::flushBuffer (this=<value optimized out>, mask=<value optimized out>, damage=<value optimized out>)
    at /var/tmp/portage/kde-base/kwin-4.4.95/work/kwin-4.4.95/kwin/scene_opengl.cpp:831
#9  0x000000307f6cace6 in KWin::SceneOpenGL::paint (this=<value optimized out>, damage=<value optimized out>, toplevels=<value optimized out>)
    at /var/tmp/portage/kde-base/kwin-4.4.95/work/kwin-4.4.95/kwin/scene_opengl.cpp:761
#10 0x000000307f6b4d1f in KWin::Workspace::performCompositing (this=<value optimized out>) at /var/tmp/portage/kde-base/kwin-4.4.95/work/kwin-4.4.95/kwin/composite.cpp:454
#11 0x000000307f63677d in KWin::Workspace::qt_metacall (this=<value optimized out>, _c=<value optimized out>, _id=<value optimized out>, _a=<value optimized out>)
    at /var/tmp/portage/kde-base/kwin-4.4.95/work/kwin-4.4.95_build/kwin/workspace.moc:583
#12 0x0000003009f7db1f in QMetaObject::activate (sender=<value optimized out>, m=<value optimized out>, local_signal_index=<value optimized out>, argv=<value optimized out>)
    at kernel/qobject.cpp:3272
#13 0x0000003009f778d9 in QObject::event (this=<value optimized out>, e=<value optimized out>) at kernel/qobject.cpp:1175
#14 0x00000030133b031c in QApplicationPrivate::notify_helper (this=<value optimized out>, receiver=<value optimized out>, e=<value optimized out>) at kernel/qapplication.cpp:4389
#15 0x00000030133b5e8d in QApplication::notify (this=<value optimized out>, receiver=<value optimized out>, e=<value optimized out>) at kernel/qapplication.cpp:4270
#16 0x000000301463a196 in KApplication::notify (this=<value optimized out>, receiver=<value optimized out>, event=<value optimized out>)
    at /var/tmp/portage/kde-base/kdelibs-4.4.95/work/kdelibs-4.4.95/kdeui/kernel/kapplication.cpp:309
#17 0x0000003009f65f3b in QCoreApplication::notifyInternal (this=<value optimized out>, receiver=<value optimized out>, event=<value optimized out>) at kernel/qcoreapplication.cpp:732
#18 0x0000003009f950f2 in QCoreApplication::sendEvent (this=<value optimized out>) at kernel/qcoreapplication.h:215
#19 QTimerInfoList::activateTimers (this=<value optimized out>) at kernel/qeventdispatcher_unix.cpp:602
#20 0x0000003009f952bc in QEventDispatcherUNIX::processEvents (this=<value optimized out>, flags=<value optimized out>) at kernel/qeventdispatcher_unix.cpp:923
#21 0x00000030134613fd in QEventDispatcherX11::processEvents (this=<value optimized out>, flags=<value optimized out>) at kernel/qeventdispatcher_x11.cpp:152
#22 0x0000003009f64c92 in QEventLoop::processEvents (this=<value optimized out>, flags=<value optimized out>) at kernel/qeventloop.cpp:149
#23 0x0000003009f65074 in QEventLoop::exec (this=<value optimized out>, flags=<value optimized out>) at kernel/qeventloop.cpp:201
#24 0x0000003009f690cb in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1009
#25 0x000000307f652d8d in kdemain (argc=<value optimized out>, argv=<value optimized out>) at /var/tmp/portage/kde-base/kwin-4.4.95/work/kwin-4.4.95/kwin/main.cpp:531
#26 0x000000300041ebbd in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, ubp_av=<value optimized out>, init=<value optimized out>, fini=<value optimized out>, 
    rtld_fini=<value optimized out>, stack_end=) at libc-start.c:226
#27 0x00000000004006c9 in _start ()
Comment 1 Niels Ole Salscheider 2010-08-03 10:19:41 UTC
This bug is the same I reported on the mailing list last week and it is related to bug 29181. Nevertheless, Kristian Høgsberg told me that it should not return NULL since there should always be a __GLXDRIdrawable in the hash table.

dri2_glx.c, line 508ff says the following:

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

I am not sure if xorg-server 1.8.2 sends invalidate events which might conflict with this function call - but then pdp->invalidateAvailable should not be false...
Comment 2 Niels Ole Salscheider 2010-08-03 11:53:20 UTC
What happens to pdp in dri2CreateDisplay(Display * dpy), dri2_glx.c? This function sets pdp->invalidateAvailable but pdp is neither stored in a global variable nor is it returned by the function (just &pdp->base and pdp->base does not contain a pointer to pdp, does it?).
Comment 3 Mario Kleiner 2010-08-03 12:11:14 UTC
(In reply to comment #1)
> This bug is the same I reported on the mailing list last week and it is related
> to bug 29181. Nevertheless, Kristian Høgsberg told me that it should not return
> NULL since there should always be a __GLXDRIdrawable in the hash table.
> 
> dri2_glx.c, line 508ff says the following:
> 
> /* Old servers don't send invalidate events */
> if (!pdp->invalidateAvailable)
>    dri2InvalidateBuffers(dpyPriv->dpy, pdraw->drawable);
> 
> I am not sure if xorg-server 1.8.2 sends invalidate events which might conflict
> with this function call - but then pdp->invalidateAvailable should not be
> false...

1.8.2 doesn't send invalidate events, so this call is correctly taken. Even if it were taken erroneously, it wouldn't matter or cause these symptoms. Could also be that something goes wrong inside


dri2InvalidateBuffers(Display *dpy, XID drawable)
{
   __GLXDRIdrawable *pdraw =
      dri2GetGlxDrawableFromXDrawableId(dpy, drawable);
   struct dri2_screen *psc = (struct dri2_screen *) pdraw->psc;
   struct dri2_drawable *pdp = (struct dri2_drawable *) pdraw;
     
when it calls dri2GetGlxDrawableFromXDrawableId() and that one returns an invalid result.

However i tested mesa master with both 1.8.2 (no invalidate events) and master (invalidate events) and it worked well. Didn't test with KWin though, so i don't know.
Comment 4 Nikos Chantziaras 2010-08-03 20:53:42 UTC
One thing I'd like to point out is that KDE with compositing is totally unusable right now at current Git master because UMS doesn't work either. KMS crashes due to the present bug, and UMS crashes because of bug 28181.

So if a developer could install KDE4 and try to reproduce, that would be really awesome.
Comment 5 Kristian Høgsberg 2010-08-04 05:51:07 UTC
(In reply to comment #0)
> KWin crashes when trying to activate OpenGL desktop effects.  I do not know if
> bug 29181 is related; could be.
> 
> I'm on Mesa git master, kernel 2.6.35 using Radeon KMS, xorg-server 1.8.2,
> xf86-video-ati git master, Radeon HD4870.
> 
> This is the backtrace:
> 
> Application: KWin (kwin), signal: Segmentation fault
> [KCrash Handler]
> #6  dri2InvalidateBuffers (dpy=<value optimized out>, drawable=<value optimized
> out>) at dri2_glx.c:643
> #7  0x0000003008c5106d in dri2SwapBuffers (pdraw=<value optimized out>,
> target_msc=<value optimized out>, divisor=<value optimized out>,
> remainder=<value optimized out>) at dri2_glx.c:510

Ah, I see, this is the compatibility path for servers that don't send invalidate events.  When dri2SwapBuffers call dri2Invalidate handle it passes the GLX drawable XID, but that's wrong, it should pass the X drawable XID.  I just committed:

commit 9da1c9da139327132dea57b18048a4eb386b6bad
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Wed Aug 4 08:43:08 2010 -0400

    glx: dri2InvalidateBuffers() needs the X drawable XID not the GLX one
    
    This never ceases to entertain.

to mesa master, please give it a try.
Comment 6 Nikos Chantziaras 2010-08-04 09:23:34 UTC
(In reply to comment #5)
> Ah, I see, this is the compatibility path for servers that don't send
> invalidate events.  When dri2SwapBuffers call dri2Invalidate handle it passes
> the GLX drawable XID, but that's wrong, it should pass the X drawable XID.  I
> just committed:
> 
> commit 9da1c9da139327132dea57b18048a4eb386b6bad
> Author: Kristian Høgsberg <krh@bitplanet.net>
> Date:   Wed Aug 4 08:43:08 2010 -0400
> 
>     glx: dri2InvalidateBuffers() needs the X drawable XID not the GLX one
> 
>     This never ceases to entertain.
> 
> to mesa master, please give it a try.

Thanks. Just pulled it. With this I've now got compositing to work. However, only to discover that performance is abysmal (and unfortunately I'm not overstating). Every animation seems to happen at about 10FPS; extremely skippy and uneven.

So in other words, still totally unusable :-P  Do devs really never test with KDE?
Comment 7 Niels Ole Salscheider 2010-08-04 09:41:15 UTC
I had the same problem, try to disable the function check.

Nevertheless there still seems to be the bind_tex_image problem I posted on the mailing list (NULL pointer check after the pointer was dereferenced).
Comment 8 Kristian Høgsberg 2010-08-04 09:49:44 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Ah, I see, this is the compatibility path for servers that don't send
> > invalidate events.  When dri2SwapBuffers call dri2Invalidate handle it passes
> > the GLX drawable XID, but that's wrong, it should pass the X drawable XID.  I
> > just committed:
> > 
> > commit 9da1c9da139327132dea57b18048a4eb386b6bad
> > Author: Kristian Høgsberg <krh@bitplanet.net>
> > Date:   Wed Aug 4 08:43:08 2010 -0400
> > 
> >     glx: dri2InvalidateBuffers() needs the X drawable XID not the GLX one
> > 
> >     This never ceases to entertain.
> > 
> > to mesa master, please give it a try.
> 
> Thanks. Just pulled it. With this I've now got compositing to work. However,
> only to discover that performance is abysmal (and unfortunately I'm not
> overstating). Every animation seems to happen at about 10FPS; extremely skippy
> and uneven.

Are you using the radeon dri driver for that recent pull too or just the new libGL?  I think jglisse fixed the slowness recently, not sure.  Either way, that's a different issue, closing this bug.

thanks,
Kristian
Comment 9 Kristian Høgsberg 2010-08-04 09:53:07 UTC
(In reply to comment #7)
> I had the same problem, try to disable the function check.

Which function check?
 
> Nevertheless there still seems to be the bind_tex_image problem I posted on the
> mailing list (NULL pointer check after the pointer was dereferenced).

Fixed.
Comment 10 Niels Ole Salscheider 2010-08-04 09:58:56 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > I had the same problem, try to disable the function check.
> 
> Which function check?

In KWin 's settings you can enable an OpenGL function check for all enabled effects. If I enable it some animations become quite slow.
I think I read an advice by a kde developer to try to disable it afterwards, too, so this might be a kde bug.
Comment 11 Nikos Chantziaras 2010-08-04 10:01:17 UTC
(In reply to comment #7)
> I had the same problem, try to disable the function check.
> 
> Nevertheless there still seems to be the bind_tex_image problem I posted on the
> mailing list (NULL pointer check after the pointer was dereferenced).

Disabling VSync and the functionality check in Desktop Settings seems to fix the performance drop (fortunately, VSync is still applied even when disabling it in KDE.)

While tweaking the settings, I've still got a few crashes in dri2InvalidateBuffers(), never exactly reproducible.

But at least it kind of works now. Oh, did I mention that it would be a good idea if the devs would install KDE so that they can sanity check their commits from time to time? :-)

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.