Bug 259640

I knew we somewhere leak these deleted windows, but was never able to 
reproduce it reliable. Thanks for the nice hint on how to reproduce it :-)

sorry I am not able to reproduce on two different systems

Maybe the contents of my kwinrc would be helpful?

maybe, just attach it (doesn't happen here either)

Created attachment 55054 [details]
kwinrc

My kwinrc config file.

BTW, I've just tried with a fresh kwinrc and the problem is gone.

Nope, still doesn't happen here.

I wonder how it should at all since there's a delay before the buttons show up and you use "fast" animations... :-\

Can you recreate the issue on your by "fixing" the fresh kwinrc (towards your former settings) and this way determine the culprit?

I've just tried that. The strange thing is that now I'm back to my old kwinrc and the problem still doesn't appear.

Something else must have changed. Silly me - I could make a full snapshot of the files.

I have a way to reproduce (sometimes) a similar issue by changing some 
settings in desktop effects module and closing. It's important that 
compositing gets restarted.

When the bug occurs I can see the ghost compositing module on desktop switch 
with cube animation.

I assume that a window is referrencing the deleted window and when compositing 
restarts it will not be unreffed and by that never removed.

Yes, I see that one sometimes as well. Not happened to me for a long while though.

I frequently however see another one - when switching the desktops with the desktop cube, the pager overlay doesn't dissappear from the screen. Doing another desktop switch fixes the problem. It happened quite frequently a while ago (I think that was in early 4.5.x versions), but nowdays I don't see it very often.

Just an update: After some time (unfortunately I didn't pay attention, so I can't tell exactly) the problem reappeared yesterday with the old kwinrc. The system wasn't restarted in the meantime.

I can confirm this also happens to me with kde 4.6.3 on Chakra. Suspending and resuming compositing clears the close buttons, but the "show windows" hot corner brings the close button back when you click on that window to show it. Is that the reproduce case? Can someone else try this:

- Use hot corner to show windows
- hover over a window with mouse until "close" button appears.
- click on that Window to bring it to front 
- The close button where that window was will now appear when spinning the cube
- repeat with other windows to get more close buttons appearing

Hope that helps.

this patch might implicitly fix this issue:
https://git.reviewboard.kde.org/r/101318/

Still there in kde 4.7.1

Git commit 43b90f4ffc53fbd756481baa3f5965ca9aff7571 by Martin Gräßlin.
Committed on 01/11/2011 at 06:48.
Pushed by graesslin into branch 'master'.

Don't handle closing windows while BoxSwitch is inactive

This might be the cause for ghost windows, because they got
referrenced without being unreferrenced again.
CCBUG: 259640

M  +3    -0    kwin/effects/boxswitch/boxswitch.cpp

http://commits.kde.org/kde-workspace/43b90f4ffc53fbd756481baa3f5965ca9aff7571

Git commit d81409f39a09057f592c0a3b01df995fc68c2af0 by Martin Gräßlin.
Committed on 01/11/2011 at 06:48.
Pushed by graesslin into branch 'KDE/4.7'.

Don't handle closing windows while BoxSwitch is inactive

This might be the cause for ghost windows, because they got
referrenced without being unreferrenced again.
CCBUG: 259640

M  +3    -0    kwin/effects/boxswitch/boxswitch.cpp

http://commits.kde.org/kde-workspace/d81409f39a09057f592c0a3b01df995fc68c2af0

Ghost windows are fixed but I still get ghost close buttons. This is on a few days old code from Git for KDE 4.8.And it looks like the close buttons are multiplying over time. Even if all the windows are close.

Same here - ghost close buttons still appear on KDE 4.8 RC2.

Could you both please post the output of:
grep -iE 'kwin4_effect_.*Enabled=true' `kde4-config --path config | cut -d":" -f1`/kwinrc | sed -e 's/kwin4_effect_//g; s/Enabled=true//g'

blur
coverswitch
cubeslide
dashboard
desktopgrid
dialogparent
diminactive
dimscreen
fade
highlightwindow
login
logout
maketransparent
minimizeanimation
outline
presentwindows
screenshot
slidingpopups
startupfeedback
translucency

Another thing I noticed is how now when I switched to plasma-netbook interface and then back to normal desktop interface now in addition to close buttons I also get the whole Plasma Netbook Launcher "screenshot" in the background of those close buttons.

Here's my list:

blur
boxswitch
coverswitch
cubeslide
dashboard
dialogparent
dimscreen
fade
flipswitch
glide
login
logout
maketransparent
minimizeanimation
presentwindows
screenshot
slidingpopups
startupfeedback
taskbarthumbnail
trackmouse
translucency
wobblywindows
zoom

Created attachment 70126 [details]
A screenshot of the bug

Also affects me (kde 4.8.1). Effects:

blur
boxswitch
coverswitch
cube
cubeslide
dashboard
desktopgrid
dialogparent
fade
glide
highlightwindow
login
logout
magiclamp
minimizeanimation
outline
presentwindows
screenshot
slideback
slidingpopups
startupfeedback
taskbarthumbnail
translucency
zoom

- does anybody encountering this bug NOT have either the boxswitch effect enabled or the -sidearm boxswitch in coverswitch enabled?
- does the issue remain when deactivating the fade effect?

(In reply to comment #24)
> - does anybody encountering this bug NOT have either the boxswitch effect
> enabled or the -sidearm boxswitch in coverswitch enabled?
> - does the issue remain when deactivating the fade effect?

The issue remains when deactivating fade effect.
Also the issue shows only with boxswitch turned on. Futhermore, it remains even when turning boxswitch on and off.

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

This issue is hopefully resolved in current master. It would be nice if someone could confirm once the beta for 4.9 is released.

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

I just reported Bug 311296 (duplicate), so it's still present in 4.9.4. I can't always reproduce the bug using some of the methods reported in this conversation; I can, however, always reproduce it if I have exactly two windows and close one of them in Present Windows.
(Check http://dl.dropbox.com/u/49436584/bug_cube_rotation.avi)

I'm attaching the output of "qdbus org.kde.kwin /KWin supportInformation" by request of Thomas Lübking.

Created attachment 75680 [details]
Output of "qdbus org.kde.kwin /KWin supportInformation"

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

Created attachment 77846 [details]
Another screenshot showing bug

Bug is still present in 4.10.1.

Linux navi 3.8.2-gentoo #5 SMP PREEMPT Fri Mar 8 04:18:49 CET 2013 x86_64 AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux

My box CFLAGS and CXXFLAGS
CFLAGS="-pipe -mtune=native -march=native -O2"
CXXFLAGS="-pipe -mtune=native -march=native -O2"

Created attachment 77847 [details]
qdbus org.kde.kwin /KWin supportInformation

Also qdbus org.kde.kwin /KWin supportInformation output

remaining commons:
-------------------------
kwin4_effect_login
kwin4_effect_slidingpopups
kwin4_effect_minimizeanimation
kwin4_effect_translucency
kwin4_effect_cubeslide
kwin4_effect_screenshot
kwin4_effect_fade
kwin4_effect_dialogparent
kwin4_effect_presentwindows
kwin4_effect_logout
kwin4_effect_startupfeedback

"fade" has seen a complete replacement in 4.10 - so we can probably rule it out as well.

References are hold by:
// boxswitch
// coverswitch
// desktopgrid
// explosion
// fallapart
// glide
presentwindows
// sheet
slidingpopups
// snaphelper
// wobblywindows

So it will be either slidingpopups or presentwindows itself which "forget" to unreference the window.
-> Please see whether the issue is reproducibly w/o "sliding popup" (run "kcmshell4 kwincompositing", 2nd tab)

Other than that void PresentWindowsEffect::slotWindowClosed() looks übersuspicious:

...
    winData->deleted = true;
    winData->referenced = true;
    w->refWindow();
...
    if (m_closeWindow == w) {
        m_closeWindow = 0;
        return; // don't rearrange
    }

obviously the m_closeWindow can get referenced? Should rather not happen, should it?
At least it won't be unreferenced (as not rearranged()) - and why would it be in m_windowData.

==> Anyone can try a patch?

Created attachment 77878 [details]
Ghost window

(In reply to comment #29)
> I can, however, always reproduce it if I have exactly two
> windows and close one of them in Present Windows.

Can't reproduce that, but when I kill all windows by present windows effect, the ghost window appears.

Notice: Always the last window that is closed appear as ghost. 

Order: closing A, closing B, closing: C. 
C will appear as ghost

I find the way to reproduce close button ghost.

1) Empty session without any windows around (start new empty kde session)
2) Open window (i.e dolphin)
3) Minimize window (I'm using Minimize window and Fade effect)
4) Trigger "Present Window - All desktops" using screen edge
5) Cube Animation should be affected now!

Additional condition note:
1) I do not use any taskbar plasmoid
2) I'm using yakuake, but yakuake window remain hidden all the time
3) I'm using Current Application Control plasmoid
4) I'm using Caledonia as plasma theme
5) I attached kwin support output before

Created attachment 77879 [details]
Ghost buttons

I repeated steps many times (excluding first). Each time there is another new button ghost.

(In reply to comment #34)

> -> Please see whether the issue is reproducibly w/o "sliding popup" (run
> "kcmshell4 kwincompositing", 2nd tab)

Reproduced with sliding popup effect disabled.

The method I used this time:
 1. Open two windows (in my case Konsole and Dolphin). Both windows are on one desktop.
 2. In Konsole restart KWin (kwin --replace). Konsole will remain the active window.
 3. Trigger Present all windows on all desktops.
 4. Point the Dolphin window and click to activate it.
 5. From now on the close button that appeared over the Dolphin window will show when changing desktops using the cube animation.

The bug is somewhere in Presentwindows.

I still cannot reproduce it, but the windows are unreferenced in prePaintWindow if either the effect is active or the motionmanager contains the window.

The motionmanager contains windows which are either present in the stacking order on start or which get added and are "selectable" (ie. regular windows, what the closeview is not)

The closewindow gets referenced when it's closed (for the fade-out) so there is clearly the option for a race condition (closed & referenced on deactivation and no motion, resp. reaches zero opacity "too late")

Anybody able to

a) reproduce this at will
b) compile a patched kwin

please raise hands - i want to ensure this is the cause.

Count me in, where can I find these patches?

Created attachment 77898 [details]
Patch attempt

Attached, thanks alot.

Bug is still present, even with patch, but I also compile kwin with additional debug, and I got this when ghost wnd appears. For ghost close button case I get same message. 

kwin(29328) KWin::x11ErrorHandler: kwin: X Error ( "error: BadDamage [DAMAGE+0], request: XDamageDestroy[DAMAGE+2], resource: 0x18011e8" )

Created attachment 77907 [details]
Patch attempt #2

Do not fear, there's still hope.
This one would also catch the second race (double close)

Nah, bug still present. I'm not afraid of compilation and etc. If you have some fancy debugging code that would be great, I really want to track down this problem. 

About this race condition, isn't that strange that bug appears 100% of the time?

Created attachment 77970 [details]
One more shot

One shot left.
Please check whether you can actually trigger this with nothing but PW and DG enabled.

If yes and this doesn't catch it, i'll add a refcounter property to the windows and a nice assert >-)

Hi. I'd like to add that for me this is also happening for other windows, like IntelliJ IDEA splash screen or Veromix plasmoid volume sliders window (the one that pops out when you click the icon). 
And, of course,the "close window" buttons that were on "present windows", but I already turned these off. I prefer the middle mouse button anyway. KDE 4.8.

Bug still present, Fade desktop is also affected (ghost window). Desktop Grid is unaffected.

I added video on youtube (file too big for bugtracker), http://www.youtube.com/watch?v=BTjXdGy1-qY

There's also the dolphin ghost, so this is NOT limited to the close buttons and by this all attempts can be counted as void, since the source is likely sth. different.

Please deactivate the fade effect and attempt to re-trigger this.

I wrote about the ghost window issue (comment #35) before any of these patches appeared.

It should probably be noted that it always and only (at least, for me) happens to the "special" borderless windows (splash screens, popups from plasmoids, I guess even the "pager layout" preview from time to time).

How many activities do you use?

One. Now I'm on pure 4.10.1 kwin with this patch http://wklej.org/id/981816/. Is there a way to disable activities for good?

(In reply to comment #53)
> One. Now I'm on pure 4.10.1 kwin with this patch
> http://wklej.org/id/981816/. Is there a way to disable activities for good?
given that you mention a patch you are able to compile :-) In that case look at build option KWIN_BUILD_ACTIVITIES

It's however rather not the issue (one activity).
Have you tried disabling the fade effect?

(In reply to comment #54)
> (In reply to comment #53)
> > One. Now I'm on pure 4.10.1 kwin with this patch
> > http://wklej.org/id/981816/. Is there a way to disable activities for good?
> given that you mention a patch you are able to compile :-) In that case look
> at build option KWIN_BUILD_ACTIVITIES

I'm working with portage and activities USE flag is missing :) I don't even try to check cmake build options and run cmake manually (in before no reason). But I'll create ebuild fork to do so.

(In reply to comment #55)
> It's however rather not the issue (one activity).
> Have you tried disabling the fade effect?

Maybe I'm wrong, but the video that I uploaded contain only Desktop Cube Animation and Present Window (without fade). So I already did what you asked me to do.

Created attachment 78082 [details]
Screenshot showing the bug

I'm using Chakra Linux 2013.03, Fresh installation and default configuration KDE 4.10.1, Qt4.8.4.

I have same odd behavior. In ma case (step by step).
1. Open window.
2. Minimize.
3. Trigger Present Window.
4. Close window.
5. Switch between desktop.

I'm wondering that porting from Xlib to XCB may fix this eventually. Or uncover the main reason of this.

(In reply to comment #59)
> I'm wondering that porting from Xlib to XCB may fix this eventually. Or
> uncover the main reason of this.

hardly. also i've *never* seen this.
It just seems that unmanaged windows are prone to encounter this but managed windows can as well (see video)

Can somebody encountering this for sure please attach ~/.kde/share/kwinrc?
(Yes, there's one but that's from 2010)

Created attachment 78084 [details]
Configuration of KWin (4.10.1)

Here is my configuration. Sorry I should do this before.

(In reply to comment #60)
> hardly. also i've *never* seen this

Did you try check this on custom environment? My friend Sebastian have same issue with brand new installation. His hardware is way different than my. I'll do research with Chakra on my VirtualBox, if I find that bug, Is there any chance that you will try?

ok, does not seem to be sth. in the kwin configuration... (if it happens pretty much constantly)

(In reply to comment #60)

> hardly. also i've *never* seen this.

Fun fact is: I've seen it always,  ever since I switched from Gnome+Compiz to KDE and tried to have as much of my old Compiz setup as possible. I always thought it's known-but-unfixable... 
I've had this on Intel (with Optimus) and nVidia cards (as the only one), I'm almost sure it happened on my desktop (Intel only)  as well. It's hard to find anything common for these except,  I don't know,  Polish regional settings, Debian/Ubuntu distribution, and the user (myself)...

On Friday 15 March 2013 07:55:25 you wrote:
> https://bugs.kde.org/show_bug.cgi?id=259640
> 
> --- Comment #64 from Cezar "ikari" Pokorski <kde@ikari.pl> ---
> (In reply to comment #60)
> 
> > hardly. also i've *never* seen this.
I saw it in the past but haven't seen it for quit some time. I was able to 
trigger it when a window closed while restarting compositing, but that issue 
got fixed some time ago.

For anyone not being able to reproduce this bug, please try the following method. I've successfully reproduced it in two machines with different distros and kwin settings:

(See http://dl.dropbox.com/u/49436584/bug_cube_rotation.avi)
1. Enable the option to show the close window buttons in the Present Windows settings.
2. Have exactly two windows open.
3. Use the Present Windows effect (in the video, I go to the top left corner of the screen).
4. Close one of the windows by clicking on the button that appears on its top right corner.
5. Click on the remaining window.
6. Rotate the cube.

(In reply to comment #63)
> ok, does not seem to be sth. in the kwin configuration... (if it happens
> pretty much constantly)

I successfully reproduced this bug with Chakra (without installation, live). I used different computer.

Image installation on usb disk:
dd if=/home/dev/image.iso of=/dev/sdx bs=4K(In reply to comment #63)

Fedora 18 is also affected.

Mint 14 KDE is also affected :) All distros that I tested are on x86_64.

(In reply to comment #66)
> For anyone not being able to reproduce this bug, please try the following
> method. 

Thanks. Together with Bartłomiej's config it's reproducible.
"We can fix what we can see" - i got a reputation to loose ;-)

Created attachment 78097 [details]
Toodeloo...

.... I CAN SEE YOU    >-)

I'd claim to be on a pretty good track anyway =)

ooooooh

Yeah! This patch works \o/! Thank you very much. You did great job!

Tanks! I'll just sit here and wait for it to hit Debian Testing now...

On Saturday 16 March 2013 09:02:41 you wrote:
> Tanks! I'll just sit here and wait for it to hit Debian Testing now...
good joke  :-D Debian Testing includes 4.8 - this fix will only be provided for 
4.10 or later. So once testing is unfrozen and new upstream releases come in, 
that will be fixed. Given the current speed of solving release blocker bugs I 
wouldn't be surprised if 4.11 or 4.12 are released before testing is unfrozen.

(In reply to comment #75)
> Given the current speed of solving release blocker bugs I wouldn't 
> be surprised if 4.11 or 4.12 are released before testing is unfrozen.

Yeah... I neither feel advanced enough to compile any important part of my system myself, nor corageous enough to switch to debian unstable (guess that should be more up to date), even though http://raphaelhertzog.com/2010/12/20/5-reasons-why-debian-unstable-does-not-deserve-its-name/ (I still remember all those times when I didn't have X working after reboot ;))

 > > Given the current speed of solving release blocker bugs I wouldn't
> > be surprised if 4.11 or 4.12 are released before testing is unfrozen.
> 
> Yeah... I neither feel advanced enough to compile any important part of my
> system myself, nor corageous enough to switch to debian unstable (guess that
> should be more up to date), even though
now we are totally off-topic ;-) Unstable is frozen together with testing. Only 
way to get newer versions is experimental, but that's not a complete release 
and doesn't contain kde-workspace. On the long run tanglu, which got announced 
this week might be a solution - at least I will consider switching to it as a 
base system.

Git commit 342f3a9ff2d9587601039605e42df873fa7b75a3 by Thomas Lübking.
Committed on 11/03/2013 at 16:19.
Pushed by luebking into branch 'KDE/4.10'.

keep + track m_closeWindow to keep m_winData alive
FIXED-IN: 4.10.2
REVIEW: 109509

M  +20   -6    kwin/effects/presentwindows/presentwindows.cpp

http://commits.kde.org/kde-workspace/342f3a9ff2d9587601039605e42df873fa7b75a3

Git commit 508a1da0becd739302ca28f5f1fb53967a0cfd93 by Thomas Lübking.
Committed on 11/03/2013 at 16:19.
Pushed by luebking into branch 'master'.

keep + track m_closeWindow to keep m_winData alive
FIXED-IN: 4.10.2
REVIEW: 109509

M  +20   -6    kwin/effects/presentwindows/presentwindows.cpp

http://commits.kde.org/kde-workspace/508a1da0becd739302ca28f5f1fb53967a0cfd93

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