Bug 304184

Created attachment 159628 [details]
kde-window-decorator backtrace

Has still none of the Compiz/KWD developers fixed this yet?

There is same bug open also here: http://bugs.opencompositing.org/show_bug.cgi?id=65

It is not fixed yet.

Suggested workaround is, try using another theme and see if that solves it.

I looked at this problem once before and KWD is not doing anything wrong as far as I can tell. It's obvious that something goes wrong when some of the widgets that the style engine uses are destroyed. I guess that they are either not initialized properly before being destroyed or they are destroyed more than once. Next step is to trace exactly what's going on in QT/KDE and style engine internals. Someone with more experience in these areas could probably track down the problem much more efficiently than me and it would be greatly appreciated if someone could help out here.

btw, killing line 150 in window.cpp should make the crash disappear but that will of course make kwd leak huge amounts of memory...

I cannot reproduce, is there any special setup or steps required? I've tried the one from the description and also from the linked bugreports but with no luck.

I tested this yesterday on Beta2, it always crashes when launching openoffice.

Here is the bt: http://pastebin.ca/677012

Another one after applying this http://www.pastebin.ca/677036 patch:

http://pastebin.ca/677066

There are a couple of guys from compiz-fusion team looking at it, but are yet clueless about the solution.

Hmm, I don't have access to machine with Beta2 now, and even at work I'd probably have to install it first somewhere with something less sucky than ATI.
However, if upstream developers are looking at it, I suggest running kde-window-decorator in valgrind. The backtrace looks a lot like double deletion and valgrind should pinpoint the place with the previous delete.

I actually cannot reproduce even with Beta2.

This might give some hint:

"One workaround for OpenOffice is to add "-nologo" to the startup script.
Mine (with OpenOffice 2.2 installed) is in /usr/bin/openoffice.org.2.2:
----------------
cat /usr/bin/openoffice.org2.2
#!/bin/sh
exec /etc/openoffice.org2.2/program/soffice -nologo "$@"
----------------
It seems the "window less" splash screens kills the decorator (same with Gimp splash)."

From: http://forum.compiz-fusion.org/showpost.php?p=26935&postcount=4

Both me and my colleague quite often swear over this problem ;-) Me running a 64 bit installation and he a 32 bit (both 10.3 beta 2). We also often experience crashes just after login and the desktop is loading. Backtrace from one of my crashes available at http://www.wehay.com/backtrace

There's really no need to post the same backtrace over and over again. Can you reliably reproduce the problem? Can you provide a valgrind log for kde-window-decorator? (valgrind --tool=memcheck --num-callers=40 kde-window-decorator --replace).

Created attachment 162064 [details]
Valgrind log

kwd crashes once in every 3 - 4 openoffice launches, however did not crash once when kwd was launched with valgrind.

Created attachment 162075 [details]
Output from valgrind command

Output from valgrind command when kde-window-decoration crashes, I do not know if I got it all, so please check if more is needed. Operation Start Yast2 choose -> Online Update

Lubos, are the valgrind logs any use?

I cannot duplicate it anymore on beta3.

No, not really :(. I spent a good part of Friday on IRC trying to debug this (I still cannot reproduce here) and basically I'm utterly confused. The valgrind log suggests a double delete, but according to debugging everything is deleted only once and I don't see anything wrong in the sources either.
Also, this problem seems to be triggered by a race condition somewhere in Compiz that makes it try to use a decoration even for splash windows (in KWD::Decorator::handleWindowAdded() 'frame' is set even for such windows). It might make sense to explicitly handle this case at least as a workaround.

Jonas, Matthias can you still reproduce on beta 3?

With Beta3 it looks fine for me so far ...

I did actually manage to reproduce this on beta 3. After playing around with CompizConfig Settings Manager (trying to enable the Wobbly Window plug in) caused the decorator to crasch more or less every time I logged in. However pressing "reset to default" in CCSM did not only enable Wobbly plugin but also decorator have not crashed since.

Bug 307032 also could no longer be reproduced under KDE in beta 3.  David/Jig, is there anything that could have changed to fix this upstream?

Nothing changed at all. Maybe kde updates fixed it?

doesn't look like critical if it's hard to reproduce now.

Created attachment 172684 [details]
gdb of crash

kde-window-decorator crashes 1-2 times a day for me, and I don't really see any pattern to it. I've got a gdb backtrace for the latest time it crashed (attached), but I'll try to get a valgrind one for the next time. 

I would definitely say this was critical because new users have pretty much no idea how to re-enable the window decorator short of restarting the computer.

Created attachment 172703 [details]
k-w-d valgrind log

Hrm, that gdb log is the same as the previous ones (sorry). Attaching the valgrind log I now have, not sure if this helps...

Actually kde-window-decorator still does crash from time to time. Same as before just after login and the desktop is loading. Could this have something todo with what programs are autoloaded when KDE starts ? I start kmix, kpowersave, knetworkmanager,kopete and amarok. Would it be possible to somehow always run kde-window-decorator under valgrind in order to capture my crasches ? I am not sure where kde-window-decorator is started.. 

Rgds Jonas

Since it still crashes at least 2 or so times a day on the setups I tried I'd say this was critical (if not a blocker). 

Created attachment 173569 [details]
Valgrind log of yet another kde-window-decorator crash

Funny, just after posting my previous message kde-window-decorator crasched (running under valgrind) Operation: I just changed my kopete status to online, kwallet password dialog appeared, I typed in my password and boom kde-window-decorator crashed.

can you try the compiz-kde package from home:dirkmueller?

Installed compiz-kde-0.5.4-14.1 from home:dirkmueller repository, kde-window-decorator still crashes though.

Created attachment 174067 [details]
New valgrind log

New valgrind log of a kde-window-decorator crash with new compiz-kde-0.5.4-14.1 package installed.

Missed to click the "Remove Needinfo" box.. 

Lubos, this log has a really nice catch at at the end which catches the QWidget destructor freeing info already freed in the NETWinInfo::update method.  Does this help at all?

No, sorry, it doesn't make any sense to me - the free comes from rather deep inside libX11 that QWidget dtor is not supposed to touch at all (and I don't even see how it could). Either Valgrind is getting it wrong or there's some really obscure memory corruption going on (which would be my guess - e.g. comment #27 has a very similar valgrind log but the memory free comes from a completely different and also totally unrelated place).

JP, your interpretation is wrong. the 2nd backtrace just happens to be that way because the free'd memory was reused. it doesn't have any causal connection (as you can see by "is XX bytes within a block of YY allocated" and XX is != 0. 

I've added an assert to the compiz package in home:dirkmueller. this should be helpful to track down the cause, I think. 

Created attachment 175135 [details]
New valgrind log

Installed compiz-0.5.4-16.1 and compiz-kde-0.5.4-16.1  OK ?

New log attached..

Can anyone please build a package with those commits from HEAD:
http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=c22c10e42862981a0f2293a1b68491573e39d241
http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=fd29f5552690e05017925bacdf4e55add9e5b1f1 

They are supposed to fix the issue. Unfortunately I can't reproduce the crashes, thus I can't judge myself if they fix it.

As Lubos stated correctly in comment #16, the issue only happens with windows that get a decoration first and get the decoration removed right after that, which might happen if the window sets relevant window properties (such as _NET_WM_WINDOW_TYPE) after mapping.

Previously, in such a case the frame property was not removed, which led to k-w-d adding a decoration using a non-existing window as frame window. With this code added, k-w-d should always have up-2-date frame window information.
I don't know if this issue causes the crashes, but it's at least worth testing.

I've added it to the package under home:dirkmueller

Created attachment 175555 [details]
New log

Installed compiz-0.5.4-19.1 and compiz-kde-0.5.4-19.1 from the dirkmueller repository and I am really sorry to say that it still crashes and it seem like the latest package made things even worse. I rebooted my machine 10 times and every time k-w-d crashed. The best way I found to manually produce a crash is to play around with kopete in combination with kwallet (Start,Online,Offline,Stop etc..)

New log attached...

And today it have not crashed even once, and I have not changed anything. I am utterly confused.

What happened after my 10-reboot test was that I made a nasty power off, realized now this caused my kde-profile to crash/reset since I've lost all my custom settings. A strange side effect to this is that k-w-d no longer seem to crash when it used to. Been however working with the computer for a few hours and during this k-w-d crashed twice, so the problem remains. One of these crashes I just enabled my bluetooth adapter (hw-switch) automatically starting Kbluetooth.

I am on openSUSE 10.3 kde since last few hours and rigorously launched and relaunched open office, haven't had a single kwd crash.

I am using SuSE2 theme.

Update: Test I was running was with 070930 git packages from home:cyberorg.

kwd still crashes with 0.5.4 packages :(

Created attachment 175990 [details]
Yet another log

Found another way of crashing kwd. Clicking on a film clip associated with Kaffeine quite frequently crash kwd when Kaffeine starts.

New log Attached..

I was able to cause this crash every time by switching the java path from the default of /usr/lib/jvm/jre/bin/java to /usr/lib64/jvm/jre/bin/java and loading the following page in Konqueror:

http://www.java.com/en/download/help/testvm.xml

I am running compiz as well:

libcompizconfig-0.5.2_git070824-19
compiz-0.5.4-36.1
libcompizconfig-backend-kconfig-0.5.2_git070824-20
compiz-fusion-plugins-main-0.5.2_git070824-20
python-compizconfig-0.5.2_git070825-19
compizconfig-settings-manager-0.5.2_git070825-19
compiz-kde-0.5.4-27
compiz-fusion-plugins-extra-0.5.2_git070824-19

Ok, I can reproduce quite reliably using that page. Countdown ...

compiz/kde/window-decorator/window.cpp, around line 1165:
=====
        /* XXX: is there a more appropriate way to achieve this?
           add WType_TopLevel flag so that visualRect isn't clipped
           to parent. */
        setWFlags (getWFlags () | WType_TopLevel);
=====
Congratulations to kde-window-decorator developers for this really really obscure bug (for those who can't quite enjoy the beauty of it, it's a bit like flipping a directory bit on a file directly in the filesystem).

I'm however not quite sure what to do with it, since I'm unsure about what this is trying to fix. I suggest somebody finds out upstream who did this and makes them suffer^H^H^H^H^H^Hsay what the hell this is.

*** Bug 333707 has been marked as a duplicate of this bug. ***

First I have to admit that I don't exactly have much Qt knowledge. So please excuse silly questions ;-)

Lubos, from comment #47 I conclude removing that line fixes the crashing? If yes, wouldn't it be enough to remove the WType_TopLevel flag in ~Window?
As I read the code (and observe when removing that line), it was added to prevent clipping of the title bar pixmap painting to the parent (which is a 1x1 offscreen window; that small to avoid wasting texture memory). If you have any better ideas to prevent clipping drawable drawing to their parent size, just go ahead :-)

> wouldn't it be enough to remove the WType_TopLevel flag in ~Window?

As I sait, that's a bit like directly flipping a fit in a filesystem, so this is a good fix only if you want another obscure internal corruption surface somewhen later. I suppose a better fix could be either making sure the parent is big enough so that it can't clip (which I guess means even higher texture usage because of this window, but kwd is not very resource friendly in this regard anyway), or making the windows outright toplevel and then reparenting them away to some non-Qt Xlib-only window.

We've just released compiz 0.6.2 and compiz fusion 0.6.0 try these packages and see if they work better:

Click here to start installation:

http://download.opensuse.org/repositories/X11:/XGL/openSUSE_10.3/compiz-fusion-kde.ymp

You might want to check this before installing: 

http://en.opensuse.org/Compiz_Fusion

I can confirm that this appears to fix the kde-window-decorator crash with the following website:

http://www.java.com/en/download/help/testvm.xml

Thank you!

However, I did have a dependency issue when installing the updates.

The error was: "python-compizconfig cannot be installed due to missing dependencies"

I was able to install it when I selected only that package though, oddly enough.

I'll attach a screenshot. Hopefully it will help.

Created attachment 179679 [details]
python-compizconfig cannot be installed due to missing dependencies

Error that I'm getting when installing the entire set of new packages on my system. I was able to install the package from the link if I didn't install any other packages at the same time.

That seems like either local mirror issue or you not having the main/base repository added.

If the kwd crash is gone, this bug can be closed?

I share the same experience, no crashes since I added the new package. I think however it's yet to early to say indefinently the problem is solved.

Created attachment 180036 [details]
kde-window-decorator crash backtrace after implementing patch

I have been browsing in konqueror for two days crash free, however, today I browsed to:

http://register.vmware.com/content/download.html

Clicked on the link to download the VMware Server Linux client package zip file, and got a kde-window-decorator crash.

I've attached the backtrace.

Here are the compiz packages I'm running:

compiz-0.6.2-2.1
compiz-manager-0.0.1_git071019-10.1
libcompizconfig-0.6.0-1.3
compiz-fusion-plugins-main-0.6.0-2.1
libcompizconfig-backend-kconfig-0.5.2_git070824-20
compiz-emerald-themes-0.6.0-1.1
compizconfig-settings-manager-0.6.0-1.4
compiz-fusion-plugins-extra-0.6.0-1.3
python-compizconfig-0.6.0-1.2
compiz-kde-0.6.2-2.1
compiz-emerald-0.6.0-1.1

The good news is that it appears to be better. The bad news is that there still seems to be a problem somewhere.

Lubos, thank you very much for tracking this down.

I'm to blame for the call to setWFlags. The QT docs gives the impression that those flags are not much more than hints exposed to the WM and nothing that would affect widget destruction. It's of course not the most appropriate thing to do (hence the comment I put in the code) but I can't find any better way to have QT not clip drawing to child widgets.

I guess that making the widgets toplevel and then reparenting them away might work but it could also be causing even more issues than flipping that TopLevel bit.

Making the parent big enough so that decoration widgets aren't clipped isn't a solution as the parent would have to be large enough to handle all possible top-level window coordinates. btw, kwd is pretty efficient when it comes to texture memory usage. it's using some large pixmaps for style engines to draw to but those are never bound to textures. The pixmaps that are bound to textures are always minimal.

What's the support for redirected widgets in QT4? I know that there's some support for that in there. Maybe the most appropriate way to solve this issue is by requiring version 4 of QT which likely got an appropriate way of dealing with redirected widgets...

disabling the clipping for child widget drawing (XSetSubWindowMode) would be done by setting WPaintUnclipped. 

Does that help?

QWidget::setWFlags() is protected, which hints a bit that it's internal, but fair enough. As for a solution, I'm not sure if setting WPaintUnclipped just on the top widget would work, and Qt4 is not an option either, since the decorations are for KDE3/Qt3. 

I suggest turning mCompositeWindow from QWidget to a normal X Window, creating the decoration widgets directly as toplevel QWidgets and then using XReparentWindow() to reparent into mCompositeWindow. That's actually what KWin does, so there should not be a problem (if there's one, just grepping kdebase/kwin for "decoration->widget()" should show those few places related to this).

BTW, while you're at it, completely unrelated :), please add "app->disableSessionManagement();" somewhere to main.cpp - the decorator is not supposed to be session-managed on its own, is it?

We need to prevent clipping to the parent widget so WPaintUnclipped (changing the SubWindowMode) doesn't help. btw, it's not obvious that flipping the WPaintUnclipped bit is much more appropriate than flipping the WType_TopLevel bit.

I changed the kwd code to reparent windows instead of flipping the WType_TopLevel bit. I haven't done much testing but it seems to be working. I kept mCompositeWindow a QWidget for now just to make the patch minimal but we can of course change that later..

Hm, I don't think there's really any good reason to why it shouldn't be session managed. Is it causing problems for you? kwd is an application like any other and the only reason I can think for not having it session managed would be that you might not want to have it running when compiz isn't..

Created attachment 181272 [details]
Reparent fix

I really suggest using plain X Window instead of QWidget, as Qt may do some things in response to the direct reparenting between its two widgets (it has e.g. SubstructureRedirectMask and may react to the resulting X events).

As for the session managing, the decorator's lifetime is always managed by Compiz or something that runs both, isn't it, so why should it be also session managed? During testing with Compiz I'm regularly left with kde-window-decorator silently lurking in the background without a reason (as simple as "compiz --replace" followed again by "kwin --replace").

Hi,

> I changed the kwd code to reparent windows instead of flipping the
> WType_TopLevel bit. I haven't done much testing but it seems to be working. I
> kept mCompositeWindow a QWidget for now just to make the patch minimal but we
> can of course change that later..

One thing I found is that changes made in kcontrol no longer are applied instantly. Other than that, it seems to work fine.

I've now made the mCompositeWindow an X window and fixed some issues that caused reloading of a new styles not to work.

kde-window-decorator could in theory be used by someone else than compiz. E.g. both compiz and kwin could be using it, in which case the decorator's lifetime is different than compiz's life-time... nevertheless, I've added a --sm-disable option to kwd that can be used to disable session management.

I've been running compiz-kde-0.6.2-3.1.

I have had no kde-window-decorator crashes now in over two months. I think we can consider this bug closed.

Well, it's been closer to 1.5 months, I guess.

Attempting to close bug.

(In reply to comment #65 from David Bailey)
> I've been running compiz-kde-0.6.2-3.1.
> 
> I have had no kde-window-decorator crashes now in over two months. I think we
> can consider this bug closed.

Disagree. I run the same , but it crashes....basically every time 

Make certain you are running compiz-kde-0.6.2-3.1

Create a new user account and try it again with new KDE settings.

If it's still causing problems, please respond with details/backtrace and reopen the bug.

(In reply to comment #69 from David Bailey)
> Make certain you are running compiz-kde-0.6.2-3.1

I'm running that release

> Create a new user account and try it again with new KDE settings.

oops. Is there a chance to keep the user account? It contains lots of settings.....

Can confirm that it works better with a new user-id.
anyway, losing all settings etc. is not that smart.
What part of the ~/.kde do I have to delete in order to force a similar behavior as a 'new' user id?

I'm not certain where you might be having issues.

Rather than deleting all your settings try moving ~/.kde to ~/.kde.old and logout and back in.

Then you can start moving parts of .kde back into the new folder.

I would imagine the issues would be with something in ~/.kde/share/config but I don't know for certain.