xfwm4 is not running after failed shut down / "session manager must be in idle state when requesting a shutdown"

Bug #978333 reported by Chris Bainbridge on 2012-04-10
134
This bug affects 24 people
Affects Status Importance Assigned to Milestone
Xfce4 Session
Fix Released
Medium
Xfwm4
Confirmed
Medium
xfce4-session (Ubuntu)
High
Lionel Le Folgoc
Precise
Undecided
Unassigned
Quantal
Undecided
Unassigned
Raring
High
Lionel Le Folgoc
xfwm4 (Debian)
New
Unknown
xfwm4 (Fedora)
In Progress
High

Bug Description

Using XFCE desktop. I clicked the shut down button (action button on panel) and nothing seemed to happen. I clicked it again and got:

"Failed to receive a reply from the session manager. Session manager must be in idle state when requesting a shutdown."

The desktop didn't seem to be shutting down as usual, but after some (ten or so) seconds the system did shutdown. After restart and logging in, xfwm4 is not running and needs to be manually restarted.

This is the second time that this has happened in the last two weeks after upgrading to Precise.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: xfwm4 4.8.3-1ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-22.35-generic 3.2.14
Uname: Linux 3.2.0-22-generic x86_64
ApportVersion: 2.0-0ubuntu5
Architecture: amd64
Date: Tue Apr 10 21:22:02 2012
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=linux
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: xfwm4
UpgradeStatus: No upgrade log present (probably fresh install)

Created attachment 2363
mousepad patch that displays YNC prompt on session logout (demo only, won't save if you choose "yes")

When logging out, and 2+ application issue interact requests during their save-yourself-s, and (at least?) one of them actually starts interacting, the session manager will not continue normally when the interaction completes. 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.

It's OK if there is only 1 app with interactive save yourself, or there are 2 apps, but none of them actually interacts.

For example, patch a mousepad, run 2 copies of it, type "boza" in the first copy and try to logout. A yes/no/cancel prompt will be displayed, but after you answer, the second mousepad (and thus the whole session) will remain for 1 minute - or until you close the it. YMMV, I received an ICE I/O error once.

It's not a libxfcegui4 session-client problem, I tried with non-xfce apps as well.

Maybe it's not the interaction by itself that matters, but the longer time interval between interact request and interact done?

In , 8-nick (8-nick) wrote :

Reassign to <email address hidden>.

43 comments hidden view all 103 comments

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.

14 comments hidden view all 103 comments

Description of problem:

Upgraded to centos 6.1 and rebooted. After login:
1) no window decorations ('xfwm4 --replace' fixes that).
2) no workspaces (used to be 4). (Fixable via settings manager.)

Version-Release number of selected component (if applicable):

xfce4-panel-4.8.3-2.el6.x86_64
xfce4-doc-4.8.3-1.el6.noarch
xfce4-session-4.8.1-4.el6.x86_64
xfce-utils-4.8.3-1.el6.x86_64
xfce4-session-engines-4.8.1-4.el6.x86_64
xfce4-power-manager-1.0.10-1.el6.x86_64
libxfce4ui-4.8.0-4.el6.x86_64
libxfce4util-4.8.1-2.el6.x86_64
xfce4-appfinder-4.8.0-2.el6.x86_64
xfce4-mixer-4.8.0-1.el6.x86_64
xfce4-settings-4.8.3-1.el6.x86_64
xfce4-icon-theme-4.4.3-5.el6.noarch
xfwm4-4.8.1-3.el6.x86_64

OK, a couple of restarts later: I verified that xfce4-session is not starting the window manager, and that # of workspaces is reset to 1 on every login.

Are you sure you are saving a session with xfwm4 running? and it's completing ok?

Anything in ~/.xsession-errors related to a xfwm4 crash?

Does making a new clean user show the same behavior?

"No", "no", "not tried b/c #1 is the correct answer".

So the best guess is initially, after I ran yum update and hit "restart" button on the logout dialog, the session got somehow saved with xfwm4 not running?

After that I was starting xfwm4 from an xterm without '&', I can see how that would kill the wm before saving the session.

Thanks.

Yeah, that seems to be the case. ;(

We have seen sporadic cases where a logout has a xfwm4 crash, then it doesn't get saved in the session. Causing it to not show up in later sessions. ;(

We have not been able to track down the issue. ;(

75 comments hidden view all 103 comments

I can reproduce probably this bug with:
- start empty xfce4-session
- start firefox
- start gedit and type something to have unsaved changes
- do a xfce4-logout ("/usr/bin/xfce4-session-logout --logout")
=> 60s timeout, then logout. incomplete session at startup (no gedit, no xfwm4 started by session manager).

Session works fine, if:
- firefox not running or
- gedit hat no unsaved changes or
- gedit is not running

Seems that gedit does not get any shutdown message (since it does not show any dialog) if firefox is also running.

Problem occures with up-to-date opensuse 11-4 (with X11:xfce repository) and with my Xubuntu 11.10 "Oneric Ocelot". (xfce4-session 4.8.2, 2011-12-27)

(Thanks to Jérôme Guelfucci who lead me to this bug.)

We have had several folks in Fedora reporting that their xfwm4 somehow doesn't get saved in their session. I wonder if this could be the cause. Will try and gather more info.

> start firefox
> start gedit and type something [...]

Yes. Unfortunately, with 4.8, even a single xsmp interact request may break the session logout.

55 comments hidden view all 103 comments

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..

17 comments hidden view all 103 comments

I am not having trouble with window decorations, but I am having trouble with the number of workspaces being reset to 1. I can also set the number of workspaces manually every time I login. I'm using F16 on 686.

101 comments hidden view all 103 comments

It happened again. 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

At this point I switched to the console to cp .xsession-error, and instead of shutting down, got a dialog:

"Shutdown Failed

Unable to perform shutdown
Not Authorized

[Quit]"

Clicking the Quit button logged me out, showing in .xsession-errors:

xfsettingsd: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
xfwm4: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
terminator: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.

(nm-applet:2179): Gdk-WARNING **: nm-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.

XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
      after 22 requests (22 known processed) with 0 events remaining.

(bluetooth-applet:2212): Gdk-WARNING **: bluetooth-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.

(polkit-gnome-authentication-agent-1:2176): Gdk-WARNING **: polkit-gnome-authentication-agent-1: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.

(update-notifier:2224): Gdk-WARNING **: update-notifier: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.

blueman-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.

(evolution-alarm-notify:2255): Gdk-WARNING **: evolution-alarm-notify: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.

xfce4-session-logout: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
applet.py: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.

** (zeitgeist-datahub:2187): WARNING **: zeitgeist-datahub.vala:227: Unable to get name "org.gnome.zeitgeist.datahub" on the bus!

In http://forum.xfce.org/post.php?tid=6580 it is suggested that this is a problem with xfwm4 being removed from the session

I checked ~/.cache/sessions/xfce4-session-host:0 and it is true that xfwm4 is now missing from the session, so presumably this is why it does not get started. The question is, why does it get removed?

81 comments hidden view all 103 comments

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.

81 comments hidden view all 103 comments
Lionel Le Folgoc (mrpouit) wrote :

Yep, there are bad interactions sometimes with xfce4-session. That's why we disable session saving in Xubuntu by default to try to workaround that.

no longer affects: xubuntu-desktop
Changed in xfwm4 (Ubuntu):
status: New → Confirmed

@Lionel if you are talking about the "Automatically save session on logout" checkbox, then this settings does not get applied on shutdown. I did file an upstream bug for this but maybe it's an Ubuntu problem. https://bugzilla.xfce.org/show_bug.cgi?id=8678 'shutdown button ignores "auto save session" config'

81 comments hidden view all 103 comments

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.")

80 comments hidden view all 103 comments

Also see : bug #495361 [Xubuntu] No window manager at startup

21 comments hidden view all 103 comments

I wonder if this is what causes bug #8070 (xfwm4 not running on startup)?

Also see Launchpad https://bugs.launchpad.net/fedora/+source/xfwm4/+bug/978333 which links to bug reports on Fedora, Debian and Ubuntu

no longer affects: xfwm4 (Suse)
Changed in xfwm4 (Debian):
status: Unknown → New

Launchpad +bug/978333 describes exactly what happens if xfsm fails on logout; the reason may or may not be an interact request. And yes, xfwm4 is not restarted on the next login (though it's easy to launch it manually).

Bug #8070 looks like something different to me.

Perhaps it is not so obvious from the title of bug #8070 that it is the same, but if you read the bug description, it is the symptoms of xfwm4 not being started. Four of the users on that bug also confirm that the cause is xfwm4 not being started, because it is no longer in the saved session file.

Apparently, xfwm4 not being started at login is the most frequently reported xfce bug in forums, but nobody has managed to track down the cause. I was just wondering if this bug might be that cause, as the symptoms (logout, "session manager must be idle" error, force close of session, no xfwm4) sound the same.

22 comments hidden view all 103 comments
Jonas T. (jo-t) wrote :

I've filed a new bug report concerning the delayed logout ("session manager must be in idle state"): #1013548 (https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1013548).

Funnily enough, the same logout problem exists when using a different window manager (KWin in my case), but KWin is restarted properly on next reboot/login. You might mark yourself as affected there as well...

Jonas T. (jo-t) wrote :

Update: For me, a working - but rather dirty workaround - is to disable "save session on logout" in XFCE's settings manager (and then on the logout dialog as well!).

Unless you really need that session-save feature, just make sure, that the currently saved session includes your window manager and press "save session" once so the window manager is restarted on login. After that, you should be fine.

Bruce Fowler (brf531) wrote :

I've disabled "save session on logout" and I still see xfwm4 not starting *sometimes*. Maybe one reboot in four, I have to start it manually, or copy in a backed-up xfce4-session file. That file is still being overwritten on logout, again, *sometimes*. Annoying bug, I will post more if I can narrow down the "sometimes-factors."

You could try 'chattr +i' on your session file.

Bruce Fowler (brf531) wrote :

"You could try 'chattr +i' on your session file."

... or just make it read only. But I really would like to track this down and identify what needs to be fixed, so other folks don't fall into this trap. I need a background "watcher" that can tell me who changes a file and when. I'll try putting something together that uses "lsof", although the man page is pretty scary.

75 comments hidden view all 103 comments
In , Thvv (thvv) wrote :

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.

56 comments hidden view all 103 comments

Created attachment 4565
xfce4-session-4.8.3-fix-logout-fail-with-multiple-interacts.patch

This patch should fix the issue. In my case, this is probably also the cause of bug #8070 (XFWM4 issues at startup).

Basically there are two issues in xfce4-session:
1) With >1 interacting clients, the already interacting client gets moved from state XFSM_CLIENT_INTERACTING -> XFSM_CLIENT_WAITFORINTERACT. This looks like a typo to me, I think the author meant to set the new client to state XFSM_CLIENT_WAITFORINTERACT instead.
2) The 60 second timer is not cancelled even though the client responded in time, so even though the client is waiting in state XFSM_CLIENT_WAITFORINTERACT, it gets timed out and disconnected.

Why does this remove xfwm4 from the session?

xfwm4 always seems to request interaction. If a second client requests interaction, xfwm4 gets moved out of state XFSM_CLIENT_INTERACTING. It then sends interact done and so xfce4-session kills it!

[1342903947] Client Id = 24469b94c-4060-4fb1-aafe-b747eefc7547, send INTERACT DONE, but client is not in INTERACTING state
   Client will be disconnected now.

Bang, no more xfwm4 in the session, the session gets saved, and on next login it doesn't get run.

(Really, this should also be fixed so that xfwm4 always gets started regardless of whether or not it's in the session - a crash of xfwm4 shouldn't cause the user to lose the window manager forever, most users will not know how to switch to a console and restart xfwm4 manually)

57 comments hidden view all 103 comments

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).

56 comments hidden view all 103 comments

The patch works for me, with 2 different interactive-save applications. Not sure if the original xfce4-session nukes any clients waiting for interaction on save cancelled (it's interaction is broken, as described in this bug report), but the patched version is OK. Let's hope it'll be applied in the foreseeable future.

(In reply to comment #8)

Thanks a lot. This patch works also for me (applies to xfce4 4.10/git HEAD 499a719019... (22.7.2012) in OpenSUSE 11.4). Hope it will be applied soon :-)

After some more testing, it seems that "with 4.8, even a single xsmp interact request may break the session logout" was not a precise description, at least for my system. A single program still works fine if, and only if, xfce "Prompt on logout" is turned off. Perhaps the 4.8 logout itself uses interact - it's a logical thing to do - and so 1 more application becomes too much. (And it may be that I had the prompt turned off in my 4.6, can't remember.)

But the patched version works in all cases. Thank you, Chris. With GNOME writing their own SM, and xfce broken, I was beginning to wonder if xsmp has any future.

> Perhaps the 4.8 logout itself uses interact

It's xfwm4: xfwm4 always requests an interact because it uses libxfce4ui, libxfceui always requests interact so that it can call a program specific handler that may interact (or not).

BTW, to see what is going on with xfce4-session you can set XFSM_VERBOSE=1 in .xinitrc (or whatever your setup uses). When xfce4-session is started, it checks for this environment variable and, if present, writes a debug log to ~/.xfce4-session.verbose-log

What concerns me after the tests is that, with "Save session on logout" turned off, xfce simply kill the clients. Shoudn't it send a SmSaveGlobal, so they can ask the user for any unsaved work? It's not really a "save session", since the client states will not be saved.

I know it's a bit insolent, but Chris, can you take a look at that? If it requires too much work, some directions on how to implement it would be enough.

BTW, I noticed this bug is "assigned" to <email address hidden>, and the QA is not reading bugmail. Perhaps one of us should contact him directly?

Can someone review the patch and maybe commit it to the repository?

> Shoudn't it send a SmSaveGlobal, so they can ask the user for any unsaved work?

I don't know - what do other desktops do? https://live.gnome.org/SessionManagement/NotesOnXSMP under section "SaveYourselfRequest (p. 6)" seems to echo your complaint:

"Session managers generally don't let the client decide whether or not to save the session when calling SaveYourselfRequest; they use a combination of preferences/settings and logout-dialog buttons to decide. In theory then, the session manager should just ignore the passed-in save-type, and set the save-type of the SaveYourself messages to SmSaveGlobal or SmSaveBoth depending on whether it's just shutting down, or also saving the state. This is what ksmserver does, but old-gnome-session and xfce-session are both buggy:

xfce-session only sends SaveYourselfs at all if the user chooses to save the session (in which case it sends the SaveYourselfs with the requested save-type); if the session is not being saved, it just skips over the SaveYourself phase entirely and goes directly to Die. (Technically, that violates the spec, although it violates it in a way that no client can detect, so it doesn't really matter.)

if you pass SmSaveGlobal to xfce-session, and the user chooses to save their state, then correctly-written clients will not save their state."

It looks like it would be possible to change the behaviour to match ksmserver as described above, from a quick look I'd guess it calls sm_save_yourself_request in sm-layer.c and then xfsm_manager_save_yourself_global in xfsm-manager.c, you probably just need to override save_type there and set it to SmSaveGlobal or SmSaveBoth just above the "if (!shutdown || shutdown_save) { shutdown with save } else { shutdown without save }" code.

25 comments hidden view all 103 comments

It appears that this bug is caused by bug #1013548 "session manager must be in idle state when requesting a shutdown" so I have marked that one as a dupe of this one.

The bug is now fixed upstream ( see https://bugzilla.xfce.org/show_bug.cgi?id=5379 ) - it would be nice to see the fix in Ubuntu.

summary: - xfwm4 is not running after failed shut down
+ xfwm4 is not running after failed shut down / "session manager must be
+ in idle state when requesting a shutdown"
affects: xfwm4 (Ubuntu) → xfce4-session (Ubuntu)
Changed in xfce4-session (Ubuntu):
importance: Undecided → High
status: Confirmed → Triaged
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xfce4-session (Ubuntu Precise):
status: New → Confirmed
Changed in xfce4-session (Ubuntu Quantal):
status: New → Confirmed
Changed in xfce4-session (Ubuntu Raring):
status: Triaged → In Progress
assignee: nobody → Lionel Le Folgoc (mrpouit)
1 comments hidden view all 103 comments
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xfce4-session - 4.10.0-2ubuntu1

---------------
xfce4-session (4.10.0-2ubuntu1) raring; urgency=low

  * Merge from Debian experimental, remaining Ubuntu changes:
    - debian/patches:
      + xubuntu_ignore-gdm-lang.patch: do not set $LANG to $GDM_LANG, there's
        already an xsession script to do that, and $GDM_LANG might not contain
        a valid locale code.
      + xubuntu_set-xdg-current-desktop.patch: added. Taken from xfce4-utils,
        export XDG_CURRENT_DESKTOP=XFCE, can be useful with alacarte and
        gnome-menus. lp #927172

  * Drop now obsolete delta wrt to gnome-keyring integration. lp: #1010409
  * The patch added by the Debian upload fixes lp: #978333.

xfce4-session (4.10.0-2) experimental; urgency=low

  * debian/control:
    - recommends xscreensaver. closes: 3683865
  * debian/patches:
    - 0001-Handle-multiple-interactive-session-save-bug-5379 added, fix broken
      session in some cases. closes: #632404
  * debian/xfce4-session.lintian-overrides updated, we do use hardening flags.
 -- Lionel Le Folgoc <email address hidden> Fri, 09 Nov 2012 23:05:01 +0100

Changed in xfce4-session (Ubuntu Raring):
status: In Progress → Fix Released
46 comments hidden view all 103 comments

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

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

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

47 comments hidden view all 103 comments

Hi
Any plan to push a fix for precise ?

Jussi (jussi-lahtinen-gmail) wrote :

This bug is NOT fixed.
It still happens on Xubuntu 13.10 64bit.

xfce4-session 4.10.1-ubuntu1
xfwm4 4.10.1-2ubuntu1

Ps. people what is the hurry to close bug reports?? I constantly run into closed bug reports with unfixed bugs! Please wait for confirmation that the fix really works.

The patch is there in xfce4-session 4.10.1-ubuntu1. It's possible you've run into some variation of the same bug, or a different bug. Suggest you set XFSM_VERBOSE=1 in .xinitrc (or whatever your setup uses) and then check the debug log in ~/.xfce4-session.verbose-log and follow up to upstream bug https://bugzilla.xfce.org/show_bug.cgi?id=5379 (if it's the same bug, you should see "Client Id = %s send SAVE YOURSELF DONE, while not being in save mode. Prepare to be nuked!" which results in xfwm not being in session any more.

mikhail-777 (wpr-oxym) wrote :

It still happens on Xubuntu 14.04 LTS. Where is the fix for LTS??

mikhail, see comment #20. The fix has been in upstream for a while. If you apt-get source xfce4-session you will see that the fix is present in 14.04. Perhaps you are seeing a new bug, maybe with the same symptoms.

mikhail-777 (wpr-oxym) wrote :

Chris, I still see the bug https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1013548 , which somebody mark as duplicate of this #978333 . So it's not a duplicate.

43 comments hidden view all 103 comments

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

Changed in xfce4-session:
importance: Unknown → Medium
status: Unknown → Fix Released
Rolf Leggewie (r0lf) wrote :

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

Changed in xfce4-session (Ubuntu Quantal):
status: Confirmed → Won't Fix
22 comments hidden view all 103 comments

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.

Changed in xfwm4:
importance: Unknown → Medium
status: Unknown → Confirmed

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.

Shahar Or (mightyiam) wrote :

Hey, I'm running 17.04 and getting this message trying to shutdown xfce4. Is this supposed to be fixed?

Kev Bowring (flocculant) wrote :

@mightyiam - if you keep seeing it I'd report it anew from 17.04. For the record I've been running 17.04 since the start of the cycle and don't see it.

Shahar Or (mightyiam) wrote :

Thanks, @flocculant. Reported bug #1660963.

Changed in xfwm4 (Fedora):
importance: Unknown → High
status: Unknown → In Progress
Displaying first 40 and last 40 comments. View all 103 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.