Bug 786070 - 100% busy CPU after upgrade to 1.8
Summary: 100% busy CPU after upgrade to 1.8
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: liferea
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steven M. Parrish
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 787431 (view as bug list)
Depends On: 807602
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-31 11:05 UTC by Tim Waugh
Modified: 2012-05-08 10:54 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-08 10:54:47 UTC
Type: ---


Attachments (Terms of Use)

Description Tim Waugh 2012-01-31 11:05:19 UTC
Description of problem:
After upgrading to liferea 1.8 and restarting it, I was informed that the cache format had changed, and then the application became less and less responsive.  Finally, it stopped responding at all and was busy looping inside sqlite.

Version-Release number of selected component (if applicable):
liferea-1.8.0-1.fc16.x86_64

How reproducible:
Don't know.

(gdb) bt
#0  0x000000000042db58 in asyncRead (pFile=<optimized out>, zOut=0x15a87d0, 
    iAmt=1024, iOffset=7289856) at sqlite3async.c:703
#1  0x000000312482e61f in sqlite3OsRead (offset=7289856, amt=1024, 
    pBuf=<optimized out>, id=<optimized out>) at sqlite3.c:14309
#2  readDbPage (pPg=0x15a8788) at sqlite3.c:39608
#3  0x000000312483fdf0 in sqlite3PagerAcquire (pPager=0x1122ba8, pgno=7120, 
    ppPage=0x7fffbb6a90c8, noContent=0) at sqlite3.c:41841
#4  0x000000312483ff18 in btreeGetPage (pBt=0x10fe0d8, pgno=7120, 
    ppPage=0x7fffbb6a9118, noContent=<optimized out>) at sqlite3.c:49066
#5  0x000000312483ff84 in getAndInitPage (pBt=<optimized out>, 
    pgno=<optimized out>, ppPage=0x7fffbb6a9118) at sqlite3.c:49119
#6  0x000000312483ffe1 in moveToChild (pCur=0x299bb08, newPgno=<optimized out>)
    at sqlite3.c:51633
#7  0x000000312484014e in moveToLeftmost (pCur=0x299bb08) at sqlite3.c:51798
#8  0x000000312485c92b in sqlite3VdbeExec (p=<optimized out>)
    at sqlite3.c:67148
#9  0x0000003124860079 in sqlite3Step (p=0x1116e78) at sqlite3.c:61204
#10 sqlite3_step (pStmt=0x1116e78) at sqlite3.c:61277
#11 sqlite3_step (pStmt=0x1116e78) at sqlite3.c:61265
#12 0x000000000041eb75 in db_item_remove (id=83073) at db.c:1008
#13 0x0000000000427d85 in itemlist_remove_items (itemSet=0x21af980, 
    items=<optimized out>) at itemlist.c:510
#14 0x00000000004269b9 in itemset_merge_items (itemSet=<optimized out>, 
    list=0x1739a00, allowUpdates=1, markAsRead=0) at itemset.c:424
#15 0x0000000000422d01 in feed_process_update_result (subscription=0x1311db0, 
    result=<optimized out>, flags=0) at feed.c:271
#16 0x000000000042f49e in subscription_process_update_result (
    result=0x16d03b0, user_data=0x1311db0, flags=0) at subscription.c:232
#17 0x00000000004300ca in update_process_result_idle_cb (user_data=0x16d0370)
    at update.c:543
#18 0x0000003115444acd in g_main_context_dispatch ()
   from /lib64/libglib-2.0.so.0
#19 0x00000031154452c8 in ?? () from /lib64/libglib-2.0.so.0
#20 0x0000003115445815 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#21 0x000000311f54bbb7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#22 0x000000000041a8ab in main (argc=1, argv=0x7fffbb6a9de8) at main.c:351
(gdb) finish
Run till exit from #0  0x000000000042db58 in asyncRead (pFile=<optimized out>, 
    zOut=0x15a87d0, iAmt=1024, iOffset=7289856) at sqlite3async.c:703
readDbPage (pPg=0x15a8788) at sqlite3.c:39610
39610	      rc = SQLITE_OK;
Value returned is $1 = 0
(gdb) 
Run till exit from #0  readDbPage (pPg=0x15a8788) at sqlite3.c:39610
sqlite3PagerAcquire (pPager=0x1122ba8, pgno=7120, ppPage=0x7fffbb6a90c8, 
    noContent=0) at sqlite3.c:41842
41842	      if( rc!=SQLITE_OK ){
Value returned is $2 = 0
(gdb) 
Run till exit from #0  sqlite3PagerAcquire (pPager=0x1122ba8, pgno=7120, 
    ppPage=0x7fffbb6a90c8, noContent=0) at sqlite3.c:41842
btreeGetPage (pBt=0x10fe0d8, pgno=7120, ppPage=0x7fffbb6a9118, 
    noContent=<optimized out>) at sqlite3.c:49067
49067	  if( rc ) return rc;
Value returned is $3 = 0
(gdb) 
Run till exit from #0  btreeGetPage (pBt=0x10fe0d8, pgno=7120, 
    ppPage=0x7fffbb6a9118, noContent=<optimized out>) at sqlite3.c:49067
getAndInitPage (pBt=<optimized out>, pgno=<optimized out>, 
    ppPage=0x7fffbb6a9118) at sqlite3.c:49120
49120	    if( rc==SQLITE_OK ){
Value returned is $4 = 0
(gdb) 
Run till exit from #0  getAndInitPage (pBt=<optimized out>, 
    pgno=<optimized out>, ppPage=0x7fffbb6a9118) at sqlite3.c:49120
moveToChild (pCur=0x299bb08, newPgno=<optimized out>) at sqlite3.c:51634
51634	  if( rc ) return rc;
Value returned is $5 = 0
(gdb) 
Run till exit from #0  moveToChild (pCur=0x299bb08, newPgno=<optimized out>)
    at sqlite3.c:51634
moveToLeftmost (pCur=0x299bb08) at sqlite3.c:51795
51795	  while( rc==SQLITE_OK && !(pPage = pCur->apPage[pCur->iPage])->leaf ){
Value returned is $6 = 0
(gdb) 
Run till exit from #0  moveToLeftmost (pCur=0x299bb08) at sqlite3.c:51795
0x000000312485c92b in sqlite3VdbeExec (p=<optimized out>) at sqlite3.c:67148
67148	  rc = pOp->opcode==OP_Next ? sqlite3BtreeNext(u.bm.pCrsr, &u.bm.res) :
Value returned is $7 = 0
(gdb) 
Run till exit from #0  0x000000312485c92b in sqlite3VdbeExec (
    p=<optimized out>) at sqlite3.c:67148
[never finished]

Comment 1 Tim Waugh 2012-01-31 11:08:55 UTC
After killing it and restarting, it seems to be behaving correctly again.

Comment 2 Michael Schwendt 2012-01-31 22:21:09 UTC
JFYI, one tester reported that it had been processing data "for more than 10 minutes": https://admin.fedoraproject.org/updates/FEDORA-2012-0994/liferea-1.8.0-1.fc16

[Perhaps the upgrade has been too ambitious overall for requiring just +3 karma in bodhi.]

Comment 3 Amit Shah 2012-02-12 03:48:48 UTC
(In reply to comment #1)
> After killing it and restarting, it seems to be behaving correctly again.

That didn't work for me.  Continues consuming lots of CPU on updates even across system reboots.

Comment 4 Amit Shah 2012-02-12 03:50:01 UTC
*** Bug 787431 has been marked as a duplicate of this bug. ***

Comment 5 Paulo Anes 2012-03-25 18:33:15 UTC
liferea-1.8.3 as been released and has lots of performance improvements for systems with ext4 (with barrier=1) as in Fedora.

That release should solve this issue.

Comment 6 Emmanuel Seyman 2012-05-04 06:06:01 UTC
Tim, are you still seeing the problem with liferea 1.8.5?

Comment 7 Tim Waugh 2012-05-04 08:12:12 UTC
No, that seems to be fixed now.

Comment 8 Emmanuel Seyman 2012-05-08 10:54:47 UTC
Closing.


Note You need to log in before you can comment on or make changes to this bug.