Title bar, buttons to diminish, expand, quit window - disappeared. Windows stick to upper left-hand corner of screen with no way of moving them. A log out and log-in solved the problem. This has both been experienced in Magaeia XFCE version 4.8.1 and in Xubuntu XFCE version 4.8.0. In Xubuntu it has been necessary to force a restart of XFWM4, to solve the problem.
Looks like a dup of bug #7864 and bug #7866 but still the same problem, it works for me and I would need someone to get a core file if any, open that in gdb and do some initial investigation. Maybe try to contact your distribution maintainers, I believe they should be able to assist you in getting a backtrace with symbols.
Also, the first thing to determine is if it's really an issue at startup (ie xfwm4 is listed in the session for next restart) or if it's with the logout, ie xfwm4 is removed from the session and therefore is not restarted later. So when that happen, first thing is to check if xfwm4 is listed in your session in ~/.cache/sessions/xfce4-session-<display>
I'll look in the path the next time I experience the problem. The issue has also been posted to Mageia. They asked me to also pass a bug report on to you.
I have identified a potential crash which may occur at logout, which may cause xfwm4 to not be restarted at next login, which would explain why it's not there when you log in. Fix is in git, both branches master and xfce-4.8, could you try that and report?
Something else I've noticed (on my 4.8.2-1 debian sid package), is that if windows in a saved session are open in multiple workspaces, the symptoms do not manifest. If the symptoms do manifest (saved session with application windows in a single workspace only), the workspace count is reduced to 1.
Correction, symptoms still manifest if windows are open across every workspace. In fact, having windows open in every workspace seems to be a method to reproduce this. Looks like xfwm4 is not in the sessions file.
See comment #4
Got the git build (HEAD off of the xfce-4.8 branch) done and installed it. My testing indicates that the problem is gone (logoff/logon with applications open in all windows, followed by restart with applications open in all windows); I'll make another post in a couple days if I run into the symptoms again.
Symptoms still appearing using patched version. Any idea where a coredump might live so I can attach it?
(In reply to comment #9) > Symptoms still appearing using patched version. Any idea where a coredump might > live so I can attach it? Location and naming of core files on Linux can be set using the kernel params: kernel.core_uses_pid kernel.core_pattern You may want to check with your distribution what's the best place to set these (usually /etc/sysctl.conf) It is not clear if the program segfaults in your case or else if this is a bug in the new implementation of session management added by Nick and Stefan in 4.8, so that should be determined first. Note that a core file won't be useful in this bug report because I am not using the same distribution as you, so unless the core file contains all the debugging symbols and the binary statically linked (which is definitely not the case), I won't be able to make any sense of such a core file. Brian's put some instructions on how to help debugging here: http://spurint.org/projects/xfce4-debugging/
Just checking, but did you install the build from source in the same path as the original build or in /usr/local (default)? Was xfwm4 restarted after installation? If not, can you check if the version used is the one from the source build and not still the original one, just in case?
I made sure to drop it in /usr/bin (overwriting my distro package). >which xfwm4 /usr/bin/xfwm4 Here's the version string (xfwm4 -V): This is xfwm4 version 4.8.2git.6c6d216 (revision 6c6d216) for Xfce 4.8 Released under the terms of the GNU General Public License. Compiled against GTK+-2.24.8, using GTK+-2.24.8.
And to confirm, I've restarted xfwm several times after installing (system resets, logoffs, killing xfwm, etc).
If it crashes, I would really need at a bare minimum a backtrace to have an idea of where to look.
Hi, I have almost the same problem since I started using XFCE few months ago (Gnome3 convinced me). Debian sid here (3.1.0-1-amd64). On my side, I could not figure out exactly when it happens... maybe like 1/3 of the times. I don't think it's related to the number of open windows and/or workspaces, I would have noticed it. I guess its crashing at logout since there is no xfwm4 entry in ~/.cache/sessions (well, at least in the affected session). Also, my workspace count is not reduced to 1, but to 2 (instead of my usual 4). It's getting pretty annoying to "ALT-F2 -> xfwm4" each time, so I'd like to help. I cannot reproduce it at command, though I think I could manage it anyway. I've read http://spurint.org/projects/xfce4-debugging/. Good stufs, but before I did into building a reliable debug version, I wonder if there is a simpler way. If I install the xfwm4-dbg package provided in the Debian repository, isn't it enough? Then what should I do to make use of it? I'm a developper, but not very used to Linux dev, though I know how to use gdb. Can I launch xfwm4 in gdb with some arguments to make it use the xfwm4-dbg symbolic infos? Could you give me a hint or two?
(In reply to comment #2) > Also, the first thing to determine is if it's really an issue at startup (ie > xfwm4 is listed in the session for next restart) or if it's with the logout, ie > xfwm4 is removed from the session and therefore is not restarted later. > > So when that happen, first thing is to check if xfwm4 is listed in your session > in ~/.cache/sessions/xfce4-session-<display> Same problem on Fedora 16 Xfce (no mod). But in my case the logout, login or reboot don't have solved the issue. Only removing ~/.cache/sessions/xfce4-session-<display> have restored to the 'normal' situation. Running xfwm4 from terminal, restore the WM, but xfwm4 don't run at startup anyway..
There are two bugs for this on launchpad https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/495361 https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/978333 I do not think that this is a segfault, as there is no core dump in /var/crash, unless something catches the signal? If so, then it shouldn't, as Ubuntu has apport to detect and upload crashes. In my case, this seems to be a result of shutdown failing. I click the shutdown button, nothing happens, I click it again and it says "Failed to receive a reply from the session manager. Session manager must be in idle state when requesting a shutdown." xsession-errors shows: (xfwm4:2042): libxfce4ui-WARNING **: ICE I/O Error (xfwm4:2042): libxfce4ui-WARNING **: Disconnected from session manager. ** Message: using fallback from indicator to GtkStatusIcon ** Message: xfsm-shutdown-helper.c:1472: Using ConsoleKit to Stop
I think I have a reproducible test case: * log in * xfce loads panel, begins to restore session, loads firefox etc. * while this is happening, click on shutdown action button in panel * click on shutdown again * Get dialog popup ("Failed to receive a reply from the session manager. Session manager must be in idle state when requesting a shutdown.") * ctrl-alt-f1 (we somehow broke shutdown, and sometimes it stops and sometimes the system still shuts down, switching to the console seems to prevent consolekit from shutting down) The system will now be in a state where there is a zombie xfce4-session process, and most other xfce processes that would normally be running (the ones with --sm-client-id in the args) are not running (including xfwm4) However, there is a new xfce4-session process, and (this is a guess) perhaps it is now responsible for removing xfwm4 from the session.
Could this be caused by bug #5379 - "xfce session can't properly handle 2+ applications with interactive session save"? The description there sounds the same as what I've seen ("Instead, it will wait 1 minute, and then forcibly close the session. During this period, a second logout attempt will say that the session manager must be idle when requesting shutdown.")
I saw this too. Installed a grub update via yum. Logged out and got a shutdown fail.. may have clicked shutdown again. After a minute or so it logged me out. No window manager after logging in again. A quick workaround for me was to mv .cache bad.cache log out and back in again.
Please see bug #5379 for a fix for the issue that caused this problem in my case (xfwm4 getting removed from session file on logout due to two apps both requesting interaction).
xfwm4 was sometimes(rarely) terminating on startup, for me, and I had a focus follows mouse or something - fix was to restart startx. The error is this (RenderBadPicture at the very end): ... DBG[display.c:468] myDisplayGrabServer(): entering myDisplayGrabServer DBG[display.c:475] myDisplayGrabServer(): grabs : 2 DBG[display.c:468] myDisplayGrabServer(): entering myDisplayGrabServer DBG[display.c:475] myDisplayGrabServer(): grabs : 3 DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer DBG[display.c:495] myDisplayUngrabServer(): grabs : 2 DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer DBG[display.c:495] myDisplayUngrabServer(): grabs : 1 DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer DBG[display.c:491] myDisplayUngrabServer(): ungrabbing server DBG[display.c:495] myDisplayUngrabServer(): grabs : 0 XError: BadDamage (invalid Damage parameter) ==> XID 0x600350, Request 143, Error 151 <== XError: BadDamage (invalid Damage parameter) ==> XID 0x60034c, Request 143, Error 151 <== XError: BadDamage (invalid Damage parameter) ==> XID 0x60034c, Request 143, Error 151 <== XError: RenderBadPicture (invalid Picture parameter) ==> XID 0x5f, Request 139, Error 143 <== DBG[main.c:701] main(): xfwm4 terminated I am wondering if this recent commit fixed that 3f1b7c02ddcbb686f6f227b09f6e3017445880bf because I seem to be unable to reproduce it again, although it was rare/hard to reproduce anyway. So either that fixed it, or it's just that rare and hard to reproduce. This is from another log (also pre that commit): ... DBG[display.c:468] myDisplayGrabServer(): entering myDisplayGrabServer DBG[display.c:471] myDisplayGrabServer(): grabbing server DBG[display.c:475] myDisplayGrabServer(): grabs : 1 DBG[display.c:468] myDisplayGrabServer(): entering myDisplayGrabServer DBG[display.c:475] myDisplayGrabServer(): grabs : 2 DBG[display.c:468] myDisplayGrabServer(): entering myDisplayGrabServer DBG[display.c:475] myDisplayGrabServer(): grabs : 3 DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer DBG[display.c:495] myDisplayUngrabServer(): grabs : 2 DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer DBG[display.c:495] myDisplayUngrabServer(): grabs : 1 DBG[display.c:483] myDisplayUngrabServer(): entering myDisplayUngrabServer DBG[display.c:491] myDisplayUngrabServer(): ungrabbing server DBG[display.c:495] myDisplayUngrabServer(): grabs : 0 XError: BadDamage (invalid Damage parameter) ==> XID 0xa002c1, Request 143, Error 151 <== XError: RenderBadPicture (invalid Picture parameter) ==> XID 0x5f, Request 139, Error 143 <== DBG[main.c:701] main(): xfwm4 terminated Olivier, if you could confirm whether or not that commit fixes this, I would appreciate it very much, save me some time. Otherwise, if you have any suggestions on getting better debug for that, I'd be happy to. Thanks. PS: the logs were made with at least commit e97066e3171564b513e8211ec39c26d8381adfc3 if not a more recent one
(In reply to EmanueL Czirai from comment #22) > xfwm4 was sometimes(rarely) terminating on startup, for me, and I had a > focus follows mouse or something - fix was to restart startx. > The error is this (RenderBadPicture at the very end): > [...] > XError: RenderBadPicture (invalid Picture parameter) > ==> XID 0x5f, Request 139, Error 143 <== > DBG[main.c:701] main(): xfwm4 terminated > > I am wondering if this recent commit fixed that > 3f1b7c02ddcbb686f6f227b09f6e3017445880bf because I seem to be unable to > reproduce it again, although it was rare/hard to reproduce anyway. So either > that fixed it, or it's just that rare and hard to reproduce. > [...] > Olivier, if you could confirm whether or not that commit fixes this, I would > appreciate it very much, save me some time. Otherwise, if you have any > suggestions on getting better debug for that, I'd be happy to. Nope, none of the XError are fatal. The commit you point out is completely unrelated and purely cosmetic. Besides, the fact that you see "xfwm4 terminated" means it died gracefully, i.e. it's not a crash.
Thanks Olivier, I'll investigate further. The thing is, it only terminated when this message happened: XError: RenderBadPicture (invalid Picture parameter) ==> XID 0x5f, Request 139, Error 143 <== DBG[main.c:701] main(): xfwm4 terminated When it doesn't terminate, there's no RenderBadPicture in the log, even though there are other many BadDamage ones. I'll let you know if I find out anything. (should start a new bug(when I find something) ? because I think I was wrong to post here even though I thought the title matches my issue)
(In reply to EmanueL Czirai from comment #24) > Thanks Olivier, I'll investigate further. > The thing is, it only terminated when this message happened: > > XError: RenderBadPicture (invalid Picture parameter) > ==> XID 0x5f, Request 139, Error 143 <== > DBG[main.c:701] main(): xfwm4 terminated > > When it doesn't terminate, there's no RenderBadPicture in the log, even > though there are other many BadDamage ones. No, it's unrelated. > I'll let you know if I find out anything. (should start a new bug(when I > find something) ? because I think I was wrong to post here even though I > thought the title matches my issue) Correct, this bug is unrelated to your issue.