Compiz crash in compiz::opengl::bindTexImageGLX
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Compiz |
Triaged
|
Medium
|
Unassigned | ||
compiz (Ubuntu) |
Triaged
|
Medium
|
Unassigned |
Bug Description
This bug is not a duplicate of bug 1060327. It claims to have been fixed in newest version of Compiz but this happens to me even in the fixed version. The symptoms are also slightly different.
Compiz crashes reliably and quite fast whenever I open more than 4 windows. It also crashes with fewer windows but less often. Here's the backtrace:
Program received signal SIGSEGV, Segmentation fault.
_wordcopy_
at wordcopy.c:70
70 wordcopy.c: No such file or directory.
(gdb) bt
#0 _wordcopy_
at wordcopy.c:70
#1 0x00007fbfd33347c5 in __memmove_sse2 (dest=<optimized out>,
src=<optimized out>, len=6648) at ../string/
#2 0x00007fbfc5c8c774 in ?? ()
from /usr/lib/
#3 0x00007fbfc5b88aac in ?? ()
from /usr/lib/
#4 0x00007fbfc5962b71 in ?? ()
from /usr/lib/
#5 0x00007fbfc5c3ce21 in ?? ()
from /usr/lib/
#6 0x00007fbfc5a3d7fb in ?? ()
from /usr/lib/
#7 0x00007fbfc5b8ffad in ?? ()
from /usr/lib/
#8 0x00007fbfc6f08a15 in glXBindTexImageEXT ()
from /usr/lib/
#9 0x00007fbfc71eca6a in compiz:
#10 0x00007fbfc71e6c39 in TfpTexture:
from /usr/lib/
#11 0x00007fbfc71e7e91 in TfpTexture:
#12 0x00007fbfc71e1879 in boost::
#13 0x00007fbfc71e7982 in GLTexture:
#14 0x00007fbfc71d1221 in GLWindow::bind() () from /usr/lib/
#15 0x00007fbfc71d65ba in GLWindow:
#16 0x00007fbfc449b829 in DecorWindow:
#17 0x00007fbfc71d6557 in GLWindow:
#18 0x00007fbfb67f0d1e in UnityMTGrabHand
from /usr/lib/
#19 0x00007fbfc71d6557 in GLWindow:
#20 0x00007fbfb45d71af in unity::
intAttrib const&, CompRegion const&, unsigned int) ()
from /usr/lib/
#21 0x00007fbfc71d6557 in GLWindow:
#22 0x00007fbfb8972a29 in WallWindow:
#23 0x00007fbfc71d673d in GLWindow:
#24 0x00007fbfb45c50c2 in unity::
from /usr/lib/
#25 0x00007fbfc71d673d in GLWindow:
#26 0x00007fbfc71d6aa3 in PrivateGLScreen
from /usr/lib/
#27 0x00007fbfc71d7350 in GLScreen:
from /usr/lib/
#28 0x00007fbfb896d19f in WallScreen:
from /usr/lib/
#29 0x00007fbfc71d727e in GLScreen:
Matrix const&, CompRegion const&, CompOutput*, unsigned int) ()
from /usr/lib/
#30 0x00007fbfb45d72a3 in unity::
from /usr/lib/
#31 0x00007fbfc71d727e in GLScreen:
from /usr/lib/
#32 0x00007fbfc71dd93b in PrivateGLScreen
from /usr/lib/
#33 0x00007fbfcc0baff5 in CompositeScreen
#34 0x00007fbfcc0bc8e8 in CompositeScreen
from /usr/lib/
#35 0x00007fbfd3c0729c in CompTimer:
from /usr/lib/
#36 0x00007fbfd3c0733f in CompTimeoutSour
from /usr/lib/
#37 0x00007fbfd3c0682d in CompTimeoutSour
from /usr/lib/
#38 0x00007fbfd20ecebf in Glib::Source:
---Type <return> to continue, or q <return> to quit---
#39 0x00007fbfd1bf1a95 in g_main_
from /lib/x86_
#40 0x00007fbfd1bf1dc8 in ?? () from /lib/x86_
#41 0x00007fbfd1bf21c2 in g_main_loop_run ()
from /lib/x86_
#42 0x00000000004023cb in main ()
Changed in compiz: | |
milestone: | 0.9.9.0 → 0.9.9.2 |
Changed in compiz: | |
milestone: | 0.9.9.2 → 0.9.10.0 |
Changed in compiz: | |
milestone: | 0.9.10.0 → 0.9.11.0 |
This feels like a driver misbehaviour to me:
#13 0x00007fbfc71e7982 in GLTexture: :bindPixmapToTe xture(unsigned long, int, int, int, compiz: :opengl: :_PixmapSource) () from /usr/lib/ compiz/ libopengl. so compiz/ libopengl. so :glDraw( GLMatrix const&, GLWindowPaintAttrib const&, CompRegion const&, unsigned int) () from /usr/lib/ compiz/ libopengl. so
#14 0x00007fbfc71d1221 in GLWindow::bind() () from /usr/lib/
#15 0x00007fbfc71d65ba in GLWindow:
We never free the window pixmap while a texture is still bound to it. I checked pixmapbinding.cpp and for window pixmaps, we are always guaranteed to have a new valid pixmap for the window before we call GLTexture: :List:: clear and later call glXBindTexImageEXT on that pixmap.
The only thing I can think of is that the loose binding behaviour in the driver has changed to immediately release pixmap contents upon window destruction for redirected windows whose pixmaps were obtained with XCompositeNameW indowPixmap. I don't think that behaviour would be very smart though, for a number of reasons, so I'll double check with Pierre the next time I get a chance to talk to him.
This is definitely not dupe of bug 1060327 though. The problem there is the potential race condition involving externally managed pixmaps being freed, and then that same handle being used to bind an invalid color buffer to a texture later.
This bug is also about an invalid pixmap being bound to a texture, but in this instance we definitely have a valid reference to the texture, which is why I think the fact that the bind operation fails indicates that something else is causing that reference to be invalid when it shouldn't be.