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.
--
xsplash taking 100% CPU wi
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 disappearin
Anybody has this bug and is NOT running UNR?
** Changed in: xsplash (Ubuntu Karmic)
Assignee: Cody Russell (bratsche) => Loïc Minier (lool)
** Changed in: xsplash (Ubuntu Karmic)
Status: Confirmed => Fix Committed
--
xsplash taking 100% CPU with UNR installations
https://bugs.launch
** Branch linked: lp:xsplash
--
xsplash taking 100% CPU with UNR installations
https://bugs.launchpad.net/bugs/438458
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists
Wee, thanks Robbie for the catch
--
xsplash taking 100% CPU with UNR installations
https://bugs.launchpad.net/bugs/438458
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://l
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.
--
xsplash taking 100% CPU with UNR installations
https://bugs.launchpad.net/bugs/438458
You recei
** Attachment added: "strace of xsplash as launched by gdm's Init script in a
hanging scenario"
http://launchpadlibrarian.net/32742132/gdm-xsplash.strace
--
xsplash taking 100% CPU with UNR installations
https://bugs.launchpad.net/bugs/438458
You received this bug notification because you ar
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 || strc
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 ;).
--
xsplash taking 100% CPU with UNR installations
https://bugs.launchpad.net/bugs/438458
You receive
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.
** Attachment added: "Corrected xsplash.c file"
http://lau
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:4
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.
--
xsplash taking 100% CPU w
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...
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.
--
xsplash taking 100% CPU with UNR installations
https://bug
** Changed in: xsplash (Ubuntu Karmic)
Milestone: None => ubuntu-9.10-beta
** Changed in: xsplash (Ubuntu Karmic)
Importance: High => Critical
--
xsplash taking 100% CPU with UNR installations
https://bugs.launchpad.net/bugs/438458
You received this bug notification because you are a memb
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
--
xsplash taking 100% CPU with UNR installations
https://bugs.launchpad.net/bugs/438458
You receive
sounds like a race condition to me
--
xsplash taking 100% CPU with UNR installations
https://bugs.launchpad.net/bugs/438458
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https:/
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*.
--
xsplash taking 100% CPU with UNR installations
https://bugs.launchpad.net/bugs/438458
You received
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.
--
xsplash taki
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.
--
xspl
20 matches
Mail list logo
