| Summary: | 100% busy CPU after upgrade to 1.8 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tim Waugh <twaugh> |
| Component: | liferea | Assignee: | Steven M. Parrish <smparrish> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | amit.shah, emmanuel, pmca31, smparrish |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-05-08 10:54:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | 807602 | ||
| Bug Blocks: | |||
After killing it and restarting, it seems to be behaving correctly again. 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.] (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. *** Bug 787431 has been marked as a duplicate of this bug. *** 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. Tim, are you still seeing the problem with liferea 1.8.5? No, that seems to be fixed now. Closing. |
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]