Liferea uses a lot of CPU at times

Victor Osadci wrote:
> I used liferea 1.4.12 compiled against firefox 2 on Ubuntu 7.10 and it
> behaved properly.

Do you mean that recompiling it in Gutsy didn't show the issue? When did it show
it then, using Hardy official package, or Gutsy not official one?

Can you reproduce this with the official package in Hardy?
If so, can you strace the process when it's at 100% cpu and attach the log?
https://wiki.ubuntu.com/Strace

Thanks

Liferea 1.4.12 compiled from the release tarball on Gusty on one machine - this works ok;
On the other hand, the official hardy package does have the problem.

I'll try to get a trace, and compile liferea myself to see if this happens.

It appears to call gettimeofday an awful lot. A whole core of my dual core CPU is used when liferea is running.

My bug report was first. :(

Is this reproducible in some way? If so, can you tell us easy steps to trigger this issue?

Happened again, strace log attached.

I get this as well from time to time, but the software is still responsive while this is going on. My strace log is similar,

Changing status to confirmed.

This strange behavior happens to me too.
Randomly liferea uses 100%
I have liferea-1.4.14-0ubuntu running on Hardy up to date

Is this still an issue with liferea 1.4.14-0ubuntu3 and xulrunner-1.9 1.9~b5+nobinonly-0ubuntu1 ?

Emilio, yes, this still happens with up-to-date Hardy.

It seems to be spinning on a dead unix socket when I caught it in strace.

It appears to correlate well with embedded flash attempting to display. strace shows:

[pid 5162] read(8, 0x68f804, 4096) = -1 EAGAIN (Resource temporarily unavailable)
[pid 5162] poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}, {fd=18, events=POLLIN|POLLPRI}, {fd=42, events=POLLIN}, {fd=41, events=POLLIN}, {fd=36, events=POLLIN}, {fd=21, events=POLLIN}], 11, 0) = 0
[pid 5162] read(8, 0x68f804, 4096) = -1 EAGAIN (Resource temporarily unavailable)
[pid 5162] poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}, {fd=18, events=POLLIN|POLLPRI}, {fd=42, events=POLLIN}, {fd=41, events=POLLIN}, {fd=36, events=POLLIN}, {fd=21, events=POLLIN}], 11, 0) = 0

This is still happening to me. There is a new stable version of Liferea that has been up at SourceForge for several weeks. Any idea when this might get into Intrepid and we could backport it?

matthew wrote:
> This is still happening to me. There is a new stable version of Liferea
> that has been up at SourceForge for several weeks. Any idea when this
> might get into Intrepid and we could backport it?
>

Should be available this week (I've handed the merge to a new contributor who
said he would do it tomorrow).

Anyway, does it fixes this bug? If so, I didn't know it and I'll look at
backporting the fix to hardy-updates (-backports isn't the right place for bug
fixes, really)

A couple of hours ago I did a local upgrade to 1.4.15 using the package at GetDeb. I have not experienced this issue at all during that time. I will keep and eye on it over the next few days and will update this report if I experience any problems. My preliminary findings are favorable that this is fixed in 1.4.15.

Well, bad news... Liferea did fine while running, but when I closed it a few minutes ago, I experienced the same runaway cpu behavior, combined with not closing completely and the process needing to be killed.

matthew wrote:
> Well, bad news... Liferea did fine while running, but when I closed it a
> few minutes ago, I experienced the same runaway cpu behavior, combined
> with not closing completely and the process needing to be killed.
>

As you got the package from getdeb, you don't know which compiler and libraries
it was compiled. Does it happen if you compile your own upstream tarball? And is
it reproducible?

Liferea does not seem to officially support xulrunner-1.9, so both the latest 1.4 and 1.5 do no compile with it; Ubuntu has a patch to Liferea to make it work;

Victor Osadci wrote:
> Liferea does not seem to officially support xulrunner-1.9, so both the
> latest 1.4 and 1.5 do no compile with it; Ubuntu has a patch to Liferea
> to make it work;
>

That changed a few days ago:
http://liferea.svn.sourceforge.net/liferea/?rev=3849&view=rev
http://liferea.svn.sourceforge.net/liferea/?rev=3850&view=rev

Emilio: I have not been able to reproduce the problem using the getdeb package. I'll play with it for another day or two and see if I can make it happen again. If so, then I will go ahead and try to compile my own and test it out.

It has been two days and the behavior has not repeated using the aforementioned getdeb package...just thought I would give you an update. I will likely not bother to compile my own package as this one seems to be working well for me.

Thanks again for maintaining Liferea for Ubuntu!

this happens very frequently here. it makes liferea nearly unusable on a laptop, after some usage it will quietly increase its cpu usage to 100% and drain the battery.

using the "menu" pop-menu item only shows an empty liferea window which has to be closed with the "close" button to really quit liferea.

strace looks similar. is there any way to help debugging this problem?

Still happening to me in Hardy. Usually after quitting liferea, I find one cpu racing at 100% with process liferea-bin. Process continues forever until killed manually. I tried uninstall/ reinstall of liferea, which solved the problem for 2 days then it returned. Seems to occur after opening liferea links in Firefox.

I compiled the intrepid version for hardy and the problem still happens.

It is still spinning on the unavailable unix socket. According to gdb this happens in libxcb because it gets a xcb_connection_t with the fd of the socket. Probably the output below helps. Please tell me if you need any further information since liferea became totally unusable for me.

[b7fe3410] poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}, {fd=18, events=POLLIN|POLLPRI}, {fd=41, events=POLLIN}, {fd=36, events=POLLIN}, {fd=21, events=POLLIN}], 10, 0) = 0
[b7fe3410] gettimeofday({1214119763, 570023}, NULL) = 0
[b7fe3410] gettimeofday({1214119763, 570056}, NULL) = 0
[b7fe3410] gettimeofday({1214119763, 570083}, NULL) = 0
[b7fe3410] read(8, 0x80ca0a4, 4096) = -1 EAGAIN (Resource temporarily unavailable)

(gdb) bt
#0 _xcb_in_read (c=0x80ca010) at xcb_in.c:499
#1 0xb716583b in xcb_poll_for_event (c=0x80ca010) at xcb_in.c:407
#2 0xb77fccc9 in ?? () from /usr/lib/libX11.so.6
#3 0xb77fcfcf in ?? () from /usr/lib/libX11.so.6
#4 0xb77fd71f in _XEventsQueued () from /usr/lib/libX11.so.6
#5 0xb77e69d2 in XPending () from /usr/lib/libX11.so.6
#6 0xb7a0e04d in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#7 0xb7a0e141 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#8 0xb76b33e0 in IA__g_main_context_prepare (context=0x80c3fb8,
    priority=0xbfe49f28) at /build/buildd/glib2.0-2.16.3/glib/gmain.c:2329
#9 0xb76b3b09 in g_main_context_iterate (context=0x80c3fb8, block=1,

(gdb) print *c
$2 = {has_error = 0, setup = 0x80cc180, fd = 8, iolock = {__data = {
      __lock = 1, __count = 0, __owner = 27035, __kind = 0, __nusers = 1, {
        __spins = 0, __list = {__next = 0x0}}},
    __size = "\001\000\000\000\000\000\000\000\233i\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 1}, xlib = {lock = 1, sloppy_lock = 1,
    thread = 3071129376, cond = {__data = {__lock = 0, __futex = 0,
        __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0,
        __nwaiters = 0, __broadcast_seq = 0},
      __size = '\0' <repeats 47 times>, __align = 0}}, in = {event_cond = {
      __data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0,
        __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0},
      __size = '\0' <repeats 47 times>, __align = 0}, reading = 0,
    queue = "q\000WB\001\000�\003~\003 \003\001\000\000\000}9J\004}9J\004\210��\b�\226��q\000WB\001\000�\003~\003 \003\001\000\000\000}9J\004}9J\004\210��\b�\226��q\000WB\001\000�\003~\003 \003\001\000\000\000}9J\004}9J\004\210��\b�\226��q\000WB\001\000�\003~\003 \003\001\000\000\000}9J\004}9J\004\210��\b�\226��q\000WB\001\000�\003~\003 \003\001\000\000\000}9J\004}9J\004\210��\b�\226��q\000WB\001\000�\003~\003 \003\001\000\000\000}9J\004}9J\004\210��\b�\226��q\000WB\001\000�\003"..., queue_len = 0, request_expected = 213591, request_read = 213591,
    request_completed = 213590, current_reply = 0x0,
    current_reply_tail = 0x80cb0b4, replies = 0x80c3ed0, events = 0x0,
    events_tail = 0x80cb0c0, readers = 0x0, pending_replies = 0x0,
    pendi...

http://liferea.blogspot.com/2008/07/serious-problems-with-xulrunner-19.html

Emilio's liferea.blogspot now says the cpu hogging problem seems to be fixed in liferea version 1.4.18. I'm hoping this update will be added to an Ubuntu repo soon.

1.4.18 has been uploaded to sourceforge with a note that this release fixes this particular bug (as Ubeaut has also noted). Has anyone packaged it for testing?

http://sourceforge.net/forum/forum.php?forum_id=850481

I am experiencing this bug as well. It appears to be triggered by Flash in feeds, and is 100% reproducible. Steps:

1. view a feed item that contains embedded flash
 (This feed contains a number of items with embedded flash: http://paleo-future.blogspot.com/feeds/posts/default)
2. Voila! Liferea is using 100% CPU and does not stop until you kill -9 it

I'm seeing those CPU spikes too but they usually last 1 or 2 minutes, then everything goes back to normal.

It seems to me it's related to sqlite3, or to the history code as I see liferea deleting the same entries over and over again.

Here is how I saw that:

- start liferea that way: liferea --debug-all 2>&1 | tee /tmp/lf.log
- let it run for a while (several hours to a day)
- in a shell, try this: grep 'removing item with id' /tmp/lf.log | sort | uniq -c | sort -n | awk '{ print $1 }' | uniq -c

it will list how many time each unique item has been removed.

In my case, I get that:

      1 1
     21 2
    234 3
      1 4
     26 5
    176 6
      1 7
      9 8
      5 9
      1 10
      1 11
     19 12
      8 13
      3 14
      2 15
      4 16
     22 17
    669 18
      3 19
      3 20
     25 21
     16 23
     28 24
      8 25
     18 26
    855 27
   6450 28
   1175 30

I think that's what 1.4.18 is supposed to address..

I just packaged 1.4.18.

If someone wants to give it a try, it's in my PPA (intrepid only): https://launchpad.net/~fta/+archive
If after a few hours from now I feel it's better, I'll look for a sponsor. BTW, I'm not sure I should make it close this bug as it seems we have two or three different issues here.

Confirmed. Entries are now removed only once and for all. No more CPU spikes for me.

liferea 1.4.18 is available in Intrepid.

Fabien Tassin :

What different issues do you experience ? Do you experience the same issues with the package from intrepid ?

I think Fabien meant it's now fixed with 1.4.18.

Fabien, could you clarify whether this is fixed now or not?

I confirm the issue is gone now that 1.4.18 is in intrepid.
In other words, liferea in intrepid is all fine now.

.... i mean, for the problem i reported in comment #29.
I didn't close this bug because I'm not sure this is the same as the one originally reported, i.e. i had regular cpu spikes, so it doesn't match "starts using a core at 100% and does not stop until killed".

Emilio, I let you decide to close or not.

Thanks for your answer.

As I haven't suffered this bug at all, could anybody check whether this still happens with 1.4.18 in Intrepid?

Thanks

On Thu, Sep 04, 2008 at 12:00:14PM -0000, Emilio Pozuelo Monfort wrote:
> As I haven't suffered this bug at all, could anybody check whether this
> still happens with 1.4.18 in Intrepid?

So far, so good. I haven't see the 100% CPU issue again since
upgrading, and it usually manifests within a few hours.

Thanks for checking. Closing as fixed.

I'm re-opening this. It just started happening again. I think it is related to flash -- prior to today I hadn't read any items with flash content. Today, I went through several (none played since flash is very broken on amd64 in intrepid), but the CPU got stuck at 100% again. Here's what strace showed:

[pid 12451] poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN}, {fd=14, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=17, events=POLLIN|POLLPRI}, {fd=18, events=POLLIN|POLLPRI}, {fd=21, events=POLLIN}, {fd=42, events=POLLIN}, {fd=41, events=POLLIN}, {fd=36, events=POLLIN}, {fd=9, events=POLLIN}], 12, 0) = 0
[pid 12451] write(28, "\372", 1) = 1
[pid 12451] read(3, 0x261cac4, 4096) = -1 EAGAIN (Resource temporarily unavailable)

interesting.
if it's flash related, then i'm having the same problem with prism (greader) when i read rss entries containing flash videos (youtube like) or sounds (podcasts). It started a few months ago (nonfree flash 10) but i thought it was isolated to prism. Maybe it's not.

The rss feeds i still read in liferea don't contain any flash, those I read in greader do quite a lot.

Liferea can use a lot of cpu at times for me in Hardy (liferea 1.4.14-0ubuntu4). If it starts using cpu it still responds (bit slower) but the increased cpu usage won't stop until I close liferea.

I'm going to prevu Hardy from intrepid and see whether this solves the issue for me.

I've prevu'ed liferea from Intrepid and also turned of the "show items of all childs feeds" option. Liferea still uses quite some cpu sometimes but at least the cpu usage returns to normal now.

I thought it was solved for me :
https://bugs.launchpad.net/ubuntu/+source/liferea/+bug/203157/comments/42

But I was too happy too soon (too little testing). Liferea still uses a lot of cpu at times and I still need to restart liferea to stop it.

http://liferea.blogspot.com/2008/07/fix-for-100-cpu-usage-problem.html

to Emilio Pozuelo Monfort:

The bug is not fixed though with 1.14.18.

I've prevu'ed liferea from Intrepid (1.14.18) and also turned of the "show items of all childs feeds" option. Liferea still uses quite some cpu sometimes and I need to restart liferea to stop it.

ubuntu_demon wrote:
> to Emilio Pozuelo Monfort:
>
> The bug is not fixed though with 1.14.18.
>
> I've prevu'ed liferea from Intrepid (1.14.18) and also turned of the
> "show items of all childs feeds" option. Liferea still uses quite some
> cpu sometimes and I need to restart liferea to stop it.
>

Can you test 1.4.20 from my ppa? It's supposed to fix more performance issues.

Thanks!

https://edge.launchpad.net/~pochu/+archive

I'm still having the same problem with 1.4.20-0~ppa1 on Intrepid, i.e. high CPU load and the grey window that pops up when I try to close Liferea via the tray icon.

Confirmed -- that's still what I'm seeing. The cpu loop is somewhere in
xulrunner, but it continues to elude me.

I can confirm that this bug is still happening for me in Intrepid, using Liferea 1.4.18-0ubuntu2. Every so often Liferea just starts using 100% of my CPU and will not stop -- even if I quit it -- until I kill the process.

IMHO, this bug should be much more severe than "medium." When Liferea uses up all of my CPU, my system becomes unusable, therefore Liferea is unusable until this is fixed.

Yes, this is a pretty important bug, raising the severity. Not that it will help in any way...

Upstream knows this happens for some people, and has no clue on how to fix it. Xulrunner support has been removed from Liferea trunk, and the next major series (1.6) will only support WebKit.

We will close this report with 1.6, but in the meantime I'm afraid there's not much we can do, unless anybody knows how to fix it :)

Same here, with 8.04 32bit with latest updates, and liferea version 1.4.26 locally built. I built with configure --prefix=/some/place, make and make install as a normal user.

I can reproduce the issue very reliably, I simply start liferea, select any feed on the left, hit "Search all feeds ...", enter query text, and I get 100% CPU on one core after I hit "Find". I need a killall -9 liferea-bin to stop the process. Note that I don't get the problem if I do a search when no feed is selected on the left.

It is too bad, I like the application and use it every day, I have learned to deal with this bug :-)

For 8.04, the build dependencies are as follows:
autoconf automake1.7 autotools-dev intltool libnspr4-dev libnss3-dev xulrunner-1.9-dev
libatk1.0-dev libcairo2-dev libexpat1-dev libfontconfig1-dev
libfreetype6-dev libglib2.0-dev libgtk2.0-dev libice-dev libpango1.0-dev
libpixman-1-dev libpng12-dev libpthread-stubs0 libpthread-stubs0-dev
libsm-dev libx11-dev libxau-dev libxcb-xlib0-dev libxcb1-dev
libxcomposite-dev libxcursor-dev libxdamage-dev libxdmcp-dev libxext-dev
libxfixes-dev libxft-dev libxi-dev libxinerama-dev libxrandr-dev
libxrender-dev x11proto-composite-dev x11proto-core-dev x11proto-damage-dev
x11proto-fixes-dev x11proto-input-dev x11proto-kb-dev x11proto-randr-dev
x11proto-render-dev x11proto-xext-dev x11proto-xinerama-dev xtrans-dev
libgconf2-dev libidl-dev liborbit2-dev libpopt-dev libxml-dev libxml1 libxml2-dev libxslt1-dev
libsqlite3-dev libglade2-dev

I compiled the jaunty version (1.4.23-0ubuntu2) on intrepid to see if that version fixes
the problem. It doesn't, unfortunately.

For what it's worth, I do not have this problem with liferea 1.4.24-1~getdeb1 from getdeb.net: http://www.getdeb.net/app/Liferea

I'm now running jaunty. I haven't had a repeat of the bug since a while now, even with flash installed. It used to happen every day, sometimes many times a day. I suspect the bug has been fixed, unless whatever triggered it no longer happens in my feeds. I'll let it be for a while, but if no-body reports it's been happening to them in jaunty, I'll declare this bug fixed.

On Thu, Apr 16, 2009 at 04:51:42AM -0000, Lars Wirzenius wrote:
> triggered it no longer happens in my feeds. I'll let it be for a while,
> but if no-body reports it's been happening to them in jaunty, I'll
> declare this bug fixed.

I'll second that -- no run-aways for about 3 weeks now. And it used to be
daily, if not more.

Same here. Hasn't occurred for 3 weeks, more or less. Running Intrepid.

Interesting. Is anyone still affected by this bug? What versions of liferea?

I still have this problem with Intrepid and liferea 1.4.18-0ubuntu2 (multiple times per day).

This only happens with the Xulrunner backend, so is fixed in 1.5

There's a workaround at http://sourceforge.net/mailarchive/forum.php?thread_name=20090324120800.GV3980%40sym.noone.org&forum_name=liferea-devel

Should be fixed in the 1.6 series, which we will have in Karmic.