I see this, too.  The problem is with the new idle-monitor code.  When the XSyncAlarms are created, X will loop firing events as fast as it can.

The problem seems to stem from creating both the Positive and Negative transitions at the same time.  In stead, if the code from http://mail.gnome.org/archives/gtk-devel-list/2007-July/msg00017.html is used where the alarms trigger each other, then the problem is not seen.  I'm working on adapting this code to gnome-session.

An xorg bug.  Please see:
http://mail.gnome.org/archives/desktop-devel-list/2009-January/msg00315.html

Thanks for the pointer!

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

shouldn't we maybe pop up a "you need a newer xorg, sorry" dialog rather than just hosing the system?

(In reply to comment #5)
> shouldn't we maybe pop up a "you need a newer xorg, sorry" dialog rather than
> just hosing the system?

Don't know if this is really needed but instead it should be in the GNOME 2.26 release notes and maybe configure could check for the required xorg?

I run into a similar problem and also thought that is affected to gnome-session but it looks more like on my system that gnome-desktop and gnome-settings-daemon are the problem.

If i downgrade gnome-session on GNOME 2.25.92 to a release prior to 2.25.3 (tested with 2.24.3) then the CPU stays idle for about 10-15seconds after login. After that the CPU load on one CPU core goes up to 100%. So gnome-session is not the only problem.

If i downgrade to gnome-desktop-2.24.3, gnome-settings-daemon-2.24.1, gnome-panel-2.24.3 and gnome-session-2.24.3 then the problem is gone.

There must have been a major change in either one or all of these packages that does now cause that high CPU load.

I don't like the idea to make a specific xorg-server version a dependecy to the GNOME desktop because that would make testing more difficult when using garnome on older systems that do not have a recent version of the xorg-server installed. Upgrade xorg-server with all it's dependencies might cause more problems and isn't that easy.

Isn't it possible to track down that issue and either disable that code by checking when running configure or compile different code depending on which version of xorg is installed?

At least i can confirm that upgrade to XOrg 7.4 with xorg-server-1.5.99.903 will solve that problem on my system (Slackware 12.2, BlueWhite64 12.2) also but that requires to update more then one package on systems that are not up to date, only updating xorg-server doesn't work.

Jon: is there anything we can do to improve the situation here?

I'd say the right thing is simply to apply the patch to any xorg that is vulnerable to this bug.  Any application that uses xsync in this way will trigger this problem.  I'm sure the slackware xorg maintainers wouldn't object to this.

IMHO the problem is actually KNOWING what the problem is here. For a user, this is totally non-obvious. Sure distributions should (and most will) take care of this but some users will build 2.26 from source on, say, the last Ubuntu LTS release which probably never will be patched officially.

I applied the patch from here
http://cgit.freedesktop.org/xorg/xserver/commit/?id=1f4fb0225b278d1cf4145aebeb0bdd23dc8f62d5

to xorg-1.4.2 which is part of Slackware's XOrg packages. On a first look that patch does fix the problem with GNOME 2.25.92 and gnome-session-2.25.92 without upgrade to a more recent xorg-server release.

For Slackware users i can try to forward that patch to the Slackware maintainer but since that isn't a security update i'm not sure if that will get into the update packages. If i understood comment #10 correct then Slackware would be in the same possition as Ubuntu LTS and may not get patched officially.

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

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