compiz crashes randomly when using a Qt OpenGL Widget

Bug #204238 reported by csoler on 2008-03-20
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
compiz (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: compiz-core

I have produced in attachment a very elementary code that shows up the bug.

To reproduce:
- compile the code in attachment using Qt4
- launch/kill the produced executable a couple of times
- usually it takes a very short number of attempts to get logged out (between 1 and 3 for me).

I tried to setup a crash handler in the Advanced Desktop Settings tab, but it did not help me.

Configuration information:
- Linux cortinaire 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008 x86_64 GNU/Linux
- OpenGL renderer string: GeForce 7800 GT/PCI/SSE2
- OpenGL version string: 1.2 (2.1.1 NVIDIA 100.14.19)
- libQtOpenGL.so.4.3.2

csoler (cyril-soler) wrote :
csoler (cyril-soler) wrote :

I just forgot to say that this absolutely never happens if I disable compiz in the "Desktop effects" tab of the "Appearance preferences" window (i.e. If I set it to None). I can even switch back to "Normal" or "Custom" after launching my opengl window, and nothing bad happens. It's really when openning the window that something wrong is done (not by me ;-)

Basilio Kublik (sourcercito) wrote :

Hi there
do you still experience this issue with the latest updates in Hardy Heron?

Thanks in advance

Changed in compiz:
assignee: nobody → sourcercito
importance: Undecided → Low
status: New → Incomplete
csoler (cyril-soler) wrote :

*yes*

It took me 5 launches to get logged out brutally. I was expecting a lot from the upgrade to hardy, but at least this was not sufficient ;-)

I really hope you can do something for me, and I'm quite suprised that nobody else got this problem (I've been looking over the forums for a long time). Can anybody try my supplied code and tell me whether it's crashing too ?

Thanks
Cyril

Changed in compiz:
assignee: sourcercito → nobody
peddy (peddy22) wrote :

Compiz crashes for me too, when running ProjectM (which uses Qt)

I am running 64-bit Hardy Heron

csoler (cyril-soler) wrote :

I'm happy not to be alone anymore ;-)

I'd like to modify my previous statement: I get logged out whatever mode based on compiz I'm using (I mean Normal or Extra). The only case I dont' get logged out is by selecting None.

I'm having what appears to be a Qt4+OpenGL+compiz problem too.
The Qt4 application is something I have written which uses
multiple OpenGL windows within a single widget,
sharing display lists. Typically
what happens is that the CPU goes 100% for a few seconds
when I do things with the OpenGL windows like minimize one
(so that the others have to resize etc)

When I turn off compiz everything is well-behaved.

I am using:

Linux pooter 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux
/usr/lib/libQtOpenGL.so.4.3.4
OpenGL version string: 2.1.2 NVIDIA 169.12

korvins (katarata) wrote :

Hi,

This is much more than low priority. It happened to me 10 times in an afternoon, and it has been happening for a long time already.

Please change the importance of this, since a complete crash without possibility of recovery has to be considered high importance.

The same happens here, compiz activated, CPU is very busy (like 100%), I minimize a window, and the whole gnome crashes. It never happens when compiz is not activated.

I have everything updated, and it still crashes.

I seems randomnly but if the system is busy it happens easily.

Please update with this issue.

csoler (cyril-soler) wrote :

This bug has been triaged as "incomplete". Please tell us what additional information is needed.

As a hint, here's one suspicious error reported by valgrind on the example above:

==9600== Syscall param writev(vector[...]) points to uninitialised byte(s)
==9600== at 0x790784C: writev (in /lib/libc-2.7.so)
==9600== by 0xAF83365: (within /usr/lib/libxcb.so.1.0.0)
==9600== by 0xAF838EA: (within /usr/lib/libxcb.so.1.0.0)
==9600== by 0xAF83A1C: (within /usr/lib/libxcb.so.1.0.0)
==9600== by 0xAF84DB5: xcb_wait_for_reply (in /usr/lib/libxcb.so.1.0.0)
==9600== by 0x7DF1F77: _XReply (in /usr/lib/libX11.so.6.2.0)
==9600== by 0x7DD0B3C: XGetWindowProperty (in /usr/lib/libX11.so.6.2.0)
==9600== by 0x7DCFCFC: XGetWMHints (in /usr/lib/libX11.so.6.2.0)
==9600== by 0x5EA1B16: QWidgetPrivate::setWindowIcon_sys(bool) (in /usr/lib/libQtGui.so.4.4.0)
==9600== by 0x5E71EDF: QWidget::create(unsigned long, bool, bool) (in /usr/lib/libQtGui.so.4.4.0)
==9600== by 0x5E72CEA: QWidget::winId() const (in /usr/lib/libQtGui.so.4.4.0)
==9600== by 0x5A23E94: QGLWidget::setContext(QGLContext*, QGLContext const*, bool) (in /usr/lib/libQtOpenGL.so.4.4.0)
==9600== by 0x59FCFF6: (within /usr/lib/libQtOpenGL.so.4.4.0)
==9600== by 0x5A24F69: (within /usr/lib/libQtOpenGL.so.4.4.0)
==9600== by 0x59FD796: QGLWidget::QGLWidget(QWidget*, QGLWidget const*, QFlags<Qt::WindowType>) (in /usr/lib/libQtOpenGL.so.4.4.0)
==9600== Address 0xc03d49f is 7,111 bytes inside a block of size 8,680 alloc'd
==9600== at 0x4C220BC: calloc (vg_replace_malloc.c:397)
==9600== by 0xAF8357E: xcb_connect_to_fd (in /usr/lib/libxcb.so.1.0.0)
==9600== by 0xAF85ADF: xcb_connect (in /usr/lib/libxcb.so.1.0.0)
==9600== by 0x7DF1529: _XConnectXCB (in /usr/lib/libX11.so.6.2.0)
==9600== by 0x7DDA7C5: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==9600== by 0x5E8C795: (within /usr/lib/libQtGui.so.4.4.0)
==9600== by 0x5E2F146: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (in /usr/lib/libQtGui.so.4.4.0)
==9600== by 0x5E2FF71: QApplication::QApplication(int&, char**, int) (in /usr/lib/libQtGui.so.4.4.0)
==9600== by 0x4114BB: main (main.cpp:13)

As I don't happen to have the sources of Qt and X11, I can tell what's going on, but it seems that Qt is writing right into a X11 structure, which looks a bad idea.

csoler (cyril-soler) wrote :

Good news, well I hope so...

I wanted to use nvidia-settings to tune antialiasing parameters, and I realized that compiz does some pretty nasty manipulations of displays when used in combination with Xgl (It runs on display :2.0 or :3.0. It seems that the nvidia driver can only access display :0.0, so the nvidia-settings program complained that I didn't have the nvidia driver...)

Never mind, I uninstalled package xserver-xgl, rebooted, and now it seems that I don't get this stupid crash anymore (I had to really reboot to get rid of the bug. Logging out was not sufficient appearantly). Of course, I can't tell for sure this is a 100% working workaround, but I really tried a high number of times (40? 50?) and still no crash.

@all: Could you do the same manipulation i.e. removing xserver-xgl, reboot, and retry. This could help spotting the problem.

As a side effect, compiz works perfectly without xgl. Why do I have this installed ?? Good question. Maybe it's a heritage from previous ubuntu versions where xgl was needed to run Beryl and co.

Changed in compiz:
status: Incomplete → New
csoler (cyril-soler) wrote :

After 3 months since I uninstalled xserver-xgl, I never got logged out again. So, at least there's a workaround.

almanulinux (feliz) wrote :

(1) Qt4 openGL widgets running with compiz loose control, and the frame of the main window disappear.

(2) GoogleEarth with compiz: the mouse event click forces the application's background to black.
But the mouse move event seems to work good.

I am using ubuntu 7.10 without xgl.

Hope this can help discovering a solution to this bug.
cheers.

Scott Howard (showard314) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release (maybe live CD)? Thanks in advance.

Changed in compiz (Ubuntu):
status: New → Incomplete
Travis Watkins (amaranth) wrote :

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

Changed in compiz (Ubuntu):
status: Incomplete → Invalid
pat (p-hoffmann) wrote :

I still have this problem on ubuntu karmic 64bit, compiz, qt4

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments