xsplash taking 100% CPU sometimes

Bug #438458 reported by lsmobrian
98
This bug affects 15 people
Affects Status Importance Assigned to Milestone
xsplash
Fix Released
Critical
Cody Russell
xsplash (Ubuntu)
Fix Released
Critical
Loïc Minier
Karmic
Fix Released
Critical
Loïc Minier

Bug Description

Binary package hint: xsplash

After logging through GDM, xsplash never disappears (Desktop never shows)

in tty, top shows xsplash is at 100%

ProblemType: Bug
Architecture: i386
Date: Mon Sep 28 19:29:29 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/xsplash
NonfreeKernelModules: wl
Package: xsplash 0.8.1-0ubuntu1
ProcEnviron: SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.36-generic
SourcePackage: xsplash
Tags: ubuntu-unr
Uname: Linux 2.6.31-11-generic i686

Revision history for this message
lsmobrian (brian-j-porter) wrote :
Revision history for this message
Patrick (veinor) wrote :

This happens for me too; I can continue to the desktop with Ctrl+Alt+Backspace (after enabling it; this didn't always happen) but then xsplash continues to use 100% of CPU.

Revision history for this message
SaNuke (sanuke) wrote :

I have this bug on my EeePC 900 with ubuntu 9.10 karmic netbook remix.
gdm xsplash session 98%-100% cpu used.

Revision history for this message
Rob van Vliet (rob-van-vliet) wrote :

Same here on a EeePC 901, karmic UNR

Revision history for this message
Keith Drummond (kd353) wrote :

Same on an Advent 4211, Karmic UNR alpha 6

Revision history for this message
Cedric Anderson (jintxo) wrote :

Exactly same issue here. Asus eeePC 1000HE

I have removed xsplash package for now to be able to boot normally without having to manually kill xsplash from a vtty to get to my desktop.

Revision history for this message
Keith Drummond (kd353) wrote :

I may try the same when I get the chance, but something seems to have corrupted my folders, when I click "Files & Folders" only 3 icons now appear a nameless folder that I get a 'null folder' error, desktop icon and download folder. That is it. Not sure if this is related but only happened after this Xsplash issue.

Changed in xsplash (Ubuntu):
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Cody Russell (bratsche)
Revision history for this message
Robbie Williamson (robbiew) wrote : Re: xsplash taking 100% CPU with UNR installations

I have this happening with a Dell Mini 9 as well, but not on my laptop or desktop running standard Ubuntu Desktop.

tags: added: ubuntu-boot
summary: - xsplash taking 100% CPU
+ xsplash taking 100% CPU with UNR installations
Revision history for this message
Robbie Williamson (robbiew) wrote :

I tried running with the version in trunk to see if /var/log/gdm/xsplash.log had anything...and the file is not being created at boot. If I run at the command line (after killing the existing xsplash):
  sudo -u gdm xsplash --daemon
The log is created and xsplash runs with no problems.

Revision history for this message
theluketaylor (ekul-taylor) wrote :

I have the same issue with an acer aspire one though it appears to be intermittent.

xsplash seems to run fine with the battery removed and running on AC power. With the battery in and on AC or running on just battery xsplash uses 100% CPU and prevents the desktop from appearing.

Revision history for this message
Paul Natsuo Kishimoto (khaeru) wrote :

ekul, that is an interesting wrinkle.

I am also on an Aspire One, and I experienced the issue several times while running on battery, but just had a clean boot on AC power with the battery *in*.

Revision history for this message
Robbie Williamson (robbiew) wrote :

sounds like a race condition to me

Revision history for this message
datakid (datakid) wrote :

I get this as well. I login to a virt term and sudo pkill Xorg. This prompts me for a login again, but at least it then goes to the desktop.

Also note that this seems to be a duplicate of #439059

Steve Langasek (vorlon)
Changed in xsplash (Ubuntu Karmic):
milestone: none → ubuntu-9.10-beta
importance: High → Critical
Revision history for this message
Cody Russell (bratsche) wrote :

I can reproduce on my desktop now. Somehow something is totally b0rked if you have more than two signals. Try modifying /etc/gdm/PreSession/Default so that it passes --add-signal=foobar to xsplash. This seems to trigger the problem.

Revision history for this message
Robbie Williamson (robbiew) wrote :

Couple of debug items:

1) Redirected the log to /tmp, since I could not get xsplash to output to /var/log/gdm/ directory
2) Got the following:
===============
[02:30:19:2135674615 - MSG] xsplash started
[02:30:19:2135674849 - MSG] get_background_filename(): looking for appropriate resolution...
[02:30:19:2135674890 - MSG] ** 2560x1600 will work.
[02:30:19:2135674914 - MSG] ** 1920x1200 will work.
[02:30:19:2135674936 - MSG] ** 1680x1050 will work.
[02:30:19:2135674958 - MSG] ** 1440x900 will work.
[02:30:19:2135674980 - MSG] ** 1280x1024 will work.
[02:30:19:2135675003 - MSG] ** 1024x768 is too small, using last good size.
[02:30:19:2135675025 - MSG] ** Found a resolution: 1280x1024
[02:30:19:2135675050 - MSG] ** filename: /usr/share/images/xsplash/bg_1280x1024.jpg
[02:30:19:2135675074 - MSG] get_logo_filename(): looking for the best logo for screen width...
[02:30:19:2135675099 - MSG] ** Chose `small'
[02:30:19:2135675121 - MSG] ** logo filename is: /usr/share/images/xsplash/logo_small.png
[02:30:19:2135675144 - MSG] get_throbber_filename(): looking for the best throbber for screen width...
[02:30:19:2135675169 - MSG] ** Chose `small'
[02:30:19:2135675191 - MSG] ** throbber filename is: /usr/share/images/xsplash/throbber_small.png
[02:30:19:2135675214 - MSG] background_image = /usr/share/images/xsplash/bg_1280x1024.jpg
[02:30:19:2135675237 - MSG] logo_image = /usr/share/images/xsplash/logo_small.png
[02:30:19:2135675259 - MSG] throbber_image = /usr/share/images/xsplash/throbber_small.png
[02:30:19:2135692260 - MSG] get_logo_filename(): user provided a logo on the command line; using that
[02:30:19:2135692348 - MSG] get_throbber_filename(): user provided a throbber on the command line; using that
[02:30:19:2135980934 - MSG] throbber started (50 frames)
[02:30:25:2130122631 - MSG] received a new signal to wait for: gnome-panel
[02:30:25:2130122733 - MSG] adding signal `gnome-panel'
[02:30:28:2126350799 - MSG] received a new signal to wait for: nautilus
[02:30:28:2126350890 - MSG] adding signal `nautilus'
[02:30:29:2125290153 - MSG] received a new signal to wait for: netbook-launcher
[02:30:29:2125290241 - MSG] adding signal `netbook-launcher'
===============
3) attaching gdb to the process showed that I was stuck in a for loop in add_signal of xsplash.c...going back and forth from line 818 to 820. I had to kill the process

Revision history for this message
Christian Ide (cide) wrote :

I also have to kill xsplash on my Aspire One netbook because it uses 100% cpu after gdm. In the background all other programs already started (netbook launcher, panel, network manager, mail notifier etc.). It doesn't make any difference running on battery or AC power.

Revision history for this message
Robbie Williamson (robbiew) wrote :

Added some extra debug messages around the for loop at line 820 in xsplash.c and it looks like the problem is with how we iterate through the signal list:
[02:46:36:1158476869 - MSG] xsplash started
[02:46:36:1158477102 - MSG] get_background_filename(): looking for appropriate resolution...
[02:46:36:1158477142 - MSG] ** 2560x1600 will work.
[02:46:36:1158477165 - MSG] ** 1920x1200 will work.
[02:46:36:1158477187 - MSG] ** 1680x1050 will work.
[02:46:36:1158477209 - MSG] ** 1440x900 will work.
[02:46:36:1158477231 - MSG] ** 1280x1024 will work.
[02:46:36:1158477253 - MSG] ** 1024x768 is too small, using last good size.
[02:46:36:1158477275 - MSG] ** Found a resolution: 1280x1024
[02:46:36:1158477299 - MSG] ** filename: /usr/share/images/xsplash/bg_1280x1024.jpg
[02:46:36:1158477324 - MSG] get_logo_filename(): looking for the best logo for screen width...
[02:46:36:1158477350 - MSG] ** Chose `small'
[02:46:36:1158477372 - MSG] ** logo filename is: /usr/share/images/xsplash/logo_small.png
[02:46:36:1158477395 - MSG] get_throbber_filename(): looking for the best throbber for screen width...
[02:46:36:1158477420 - MSG] ** Chose `small'
[02:46:36:1158477442 - MSG] ** throbber filename is: /usr/share/images/xsplash/throbber_small.png
[02:46:36:1158477465 - MSG] background_image = /usr/share/images/xsplash/bg_1280x1024.jpg
[02:46:36:1158477487 - MSG] logo_image = /usr/share/images/xsplash/logo_small.png
[02:46:36:1158477509 - MSG] throbber_image = /usr/share/images/xsplash/throbber_small.png
[02:46:36:1158494635 - MSG] get_logo_filename(): user provided a logo on the command line; using that
[02:46:36:1158494724 - MSG] get_throbber_filename(): user provided a throbber on the command line; using that
[02:46:36:1158783070 - MSG] throbber started (50 frames)
[02:46:42:1152255362 - MSG] received a new signal to wait for: gnome-panel
[02:46:42:1152255466 - MSG] adding signal `gnome-panel'
[02:46:44:1150324026 - MSG] received a new signal to wait for: nautilus
[02:46:44:1150324116 - MSG] adding signal `nautilus'
[02:46:44:1150324162 - MSG] tmp->data is `gnome-panel'
[02:46:46:1148945376 - MSG] received a new signal to wait for: netbook-launcher
[02:46:46:1148945469 - MSG] adding signal `netbook-launcher'
[02:46:46:1148945494 - MSG] tmp->data is `nautilus'
[02:46:46:1148945516 - MSG] tmp->data is `gnome-panel'
[02:46:46:1148945538 - MSG] tmp->data is `gnome-panel'
[02:46:46:1148945560 - MSG] tmp->data is `gnome-panel'
[02:46:46:1148945581 - MSG] tmp->data is `gnome-panel'
[02:46:46:1148945603 - MSG] tmp->data is `gnome-panel'
[02:46:46:1148945624 - MSG] tmp->data is `gnome-panel'
[02:46:46:1148945645 - MSG] tmp->data is `gnome-panel'
(continues until I kill xsplash)

Revision history for this message
Robbie Williamson (robbiew) wrote :

Fixed it. Rewrote the for() loop at line 818 in xsplash.c to be a while() loop and used "tmp = tmp->next" to iterate through the list. The for() loop was using g_slist_next() and I think that is either broken or being used incorrectly.

Revision history for this message
Robbie Williamson (robbiew) wrote :

FYI, the file attached above has logging redirected to /tmp and extra debug messages for tmp->data, so don't simply replace the current version in trunk with it...unless you want these changes ;).

Revision history for this message
Robbie Williamson (robbiew) wrote :

It also seems that we are unnecessarily waiting for the nautilus signal in UNR, when we could begin_fade after receiving the netbook-launcher signal. FWIW, I rewrote line 1028 in xsplash.c to check for NULL or netbook-launcher, and it seemed to work better:

  if (signal_list == NULL || strcmp((gchar*)l->data,"netbook-launcher"))

I originally tried raising the timeout to 45sec (the default of 15 was timing out even before netbook-launcher sent its' signal), but the system still timed out waiting for nautilus...and IMHO we really don't need that up to begin use in UNR.

Revision history for this message
Loïc Minier (lool) wrote :
Revision history for this message
Loïc Minier (lool) wrote :

Wee, thanks Robbie for the catch

Revision history for this message
David Barth (dbarth) wrote :

Thanks Robbie, good catch! The problem indeed comes from g_slist_next using signal_list where it should use tmp.

Testing the fix with lool to confirm on another machine and releasing a new tarball.

Revision history for this message
Loïc Minier (lool) wrote :

Anybody has this bug and is NOT running UNR?

Changed in xsplash (Ubuntu Karmic):
assignee: Cody Russell (bratsche) → Loïc Minier (lool)
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xsplash - 0.8.1-0ubuntu2

---------------
xsplash (0.8.1-0ubuntu2) karmic; urgency=high

  * Include CDBS' simple-patchsys.
  * New patch, 60_slist-use-proper-var.patch, use proper var when iterating
    linked list; fixes xsplash eating all CPU and not disappearing on boot;
    thanks Robbie Williamson; LP: #438458.

 -- Loic Minier <email address hidden> Wed, 30 Sep 2009 11:47:01 +0200

Changed in xsplash (Ubuntu Karmic):
status: Fix Committed → Fix Released
Revision history for this message
datakid (datakid) wrote :

I've been using linux for 10 years and ubuntu for 4. This is the first time I've run dev software, submitted bug reports, seen the process up close. I don't know if you get told very much, but that was awesome. < 24 hours from problem developing on my system. Thanks.

Martin Pitt (pitti)
summary: - xsplash taking 100% CPU with UNR installations
+ xsplash taking 100% CPU sometimes
Revision history for this message
Loïc Minier (lool) wrote :

Fallouts of this bug:
bug #439268 xsplash: logging is quite broken
bug #439272 xsplash: doesn't test for setuid return code
bug #439278 nautilus: nautilus only sends "loaded" signal to xsplash when show_desktop is set
bug #439284 xsplash: please allow for an easy way to disable xsplash

Revision history for this message
Keith Drummond (kd353) wrote :

I just got an update for xsplash and everything seems to be fixed. Laptop booted up, logged in and went into desktop

Revision history for this message
theluketaylor (ekul-taylor) wrote :

I can also confim the 0.8.1ubuntu2 version of xsplash correctly displays the desktop when booting. It worked fine through several reboot cycles. Thank you for the quick response/fix for this issue.

Revision history for this message
Mark Fraser (launchpad-mfraz) wrote :

Not sure if this is the same bug as what I'm experiencing, but it seems to be every other boot where I can't get any further than the xplash screen and have to power down and reboot. This is with 0.8.1-0ubuntu2.

Revision history for this message
Cody Russell (bratsche) wrote :

This should be fixed in 0.8.2.

David Barth (dbarth)
Changed in xsplash:
importance: Undecided → Critical
status: New → Fix Released
assignee: nobody → Cody Russell (bratsche)
tags: added: iso-testing
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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