[Bug] Koreader continuously crashing #285
Comments
|
I think we need to check what is happening regarding memory usage. It All these bug reports however only give me the feeling it might be I hope I find free time to check during this week and especially the |
|
I have the same feeling too! In fact, it doesn't crash always when doing the same thing. Last note: most of the test I've done are in "Reflow Mode", because I use it really much, especially with techincal - huge pdf. The nightly build "koreader-nightly-20130913" appeared to be one the few releases quite stable on my device, regarding these operations. Also, if I restart the system (not the framework only), I get rid of errors at least in the first operations that I make (reflow, for example). Thank you very much for your investigations and work! |
|
Just to be clear: when you mean 'restarting the framework', you do mean a restart (ie. the boy+tree w/ progress bar screen pops up), and not just what would amount to a CTD on Windows (ie. it throws you back to the framework right away)? IIRC, on older devices, the framework restarting was a sign of something eating too much memory. If someone experiencing this can, try to periodically look at the system's vitals over SSH ;). |
|
I checked the heap usage of the pdf reflowing with valgrind command, In the 33,266,222 bytes still reachable memory, 11,845,080 bytes are used in blitbuffer cache items (CacheItem in koptinterface) and 19,888,200 bytes are used in reflowing cache items(ContextCacheItem in koptinterface). The total heap size used by koreader is supposed to be restricted by DGLOBAL_CACHE_SIZE, that's 10 MB by default. But it happens ContextCacheItems forgot to calculate their cache sizes before being inserted into the cache queue and make the total cache size well beyond the DGLOBAL_CACHE_SIZE limit. Usually kindle devices especially those with 5 firmware don't have a spare of 30 MB memory to hold the cache of koreader, but fortunately it 'crashes' the Java framework other than the koreader process. So to fix this problem we have to tell the cache manager the exact size of ContextCacheItem so that we won't cache too much. I will send a PR to fix this as soon as possible. |
This should fix koreader#285.
|
Now heap usage is more reasonable with #288: |
|
I've tryed the last nightly and it's even worse. Program closes or restart the framework continously ("tree with chargin bar"). When I'm using kindle keyboard with old version of KPV I've none of this issues, even if the device is older and the pdf are the same Are yuor fixes already in the last nightly? If not it could be for this that I don't see improvements... |
|
I still cannot reproduce the bug you mentioned above. But I suggest you restart your kindle device via the "Settings-Restart your kindle" approach and check if there is an indexer stuck in the background which may eat up almost all free memory. |
|
I've restarted lots of times, always the same. All the books are indexed, so it's not the indexer... Now, I'm testing the nightly This is old but sensibly faster then all the last revision, in every operation, also in displaying menus etc. For example, going back to the navigation menu is istantaneous. It is like using a totally different software, on Kindle Paperwhite at least It seems that at every release koreader become slower and heavier, don't know if depends on new functionalities... |
|
Maybe we need to introduce a way to monitor memory usage and write |
|
Thank you for your efforts, guys... P.S. I don't think it depends so much on remains because also after restarting the whole system it crashes immediatly at the same way |
|
Another thing: in reflow mode, with a big scanned book, if I open it, then go to the next page, and go to the previous page twice in a little time, it always crashes the framework (with every nightly build). If instead I wait some time and let it load before switching pages, it only hangs a moment then load the critical page without crashing the framework. Go back and forth fast in big reflowed documents should be the best way to reproduce this bug on Kindle PW (especially, going back to unrendered pages fast). The weirdest thing is that the same books are rendered perfectly and super-fast with KPV on old Kindle 3, and no crashes at all o.O Talking about the framework, I really prefer when koreader crashes itself. When the framework crashes, I must wait until it reload, than quitting koreader (because during and after frame restart is bugged) and restart koreader |
|
Might be worth checking if it behaves better with the framework down (stop lab126_gui)... But to answer hwhw: in my experience, really bad. You're much more likely to bring the system to its knees with kswapd trying to swap pages like crazy before the OOM actually deigns doing something drastic about it. I'd really like to see which state the system is in before you experience your crashes, if you can get an SSH shell up & running in parallel to see what top & its procfs friends (namely meminfo/vmstat/zoneinfo) say, that'd be great :). Barring that, a redistributable file that breaks reliably so we could try to reproduce it? |
|
I doubt that the Kindle Paperwhite/Touch has any single bit of random
|
|
@NiLuJe sorry but i'm not so expert to use ssh etc.... About the restributable file, I've only copyright protected ones :( Like feynman lectures vol 2. But you can search for huge (30+ megabyte) scanned pdf on scribd... after turning ON the reflow mode, closing the document, reopening it and change fast pages back (mainly) and forth you should get the same crashes easily on PW. @chrox You are totally right, they both have 256 megabyte of ram... firmware 5 grrr! If you need further tests that don't involve ssh and other techincal skills, just ask me! I can also try a framework-down version if you provide me the files or strings to replace for make koreader run in this mode. |
The comment below is under review, because I'm not sure that the framework always stops this way (it did the first time but now not with a new koreader version o.O)(NEW) UPDATE: I've tried to make it run in a framework down mode, calling the software with --framework_stop and substituting in koreader.sh "/etc/init.d/framework stop" with "/mnt/base-mmc/etc/init.d/framework stop". Now it seems to not crash anymore!!! I've created a KUAL entry for this mode and I'll always use it when i have to open big files or reflow them Fixes for koreader.sh: #check if we are supposed to shut down the Amazon framework #always try to continue cvm New kual entry: |
|
I give up, don't know how did I manage to make it work frameworkless, but it has been great the few times i get the program run without the it (still can't understand how I did, maybe bugs or luck). I've tried also the "stop framework" only command, but it blocks all the code that comes later and makes the device unusable |
|
I succeded to make it work without framework. Now no more crash, and great performance! |
|
Ah, the identity of the mysterious OP is revealed ;). Cf PR #294 for the 'no framework' workaround ;). That still leaves the fact that something's possibly too grabby with memory somewhere, but at least it gives users an alternative. |
|
Thank you for committing! |
On Kindle Paperwhite 5.3.4, koreader-nightly-20130913 was very stable and crashed rarely. With the last update it crashes continuously in all sort of operation (reflowing sometimes, resizing text some others, page changes, etc), especially with heavy pdf documents. With "crashes" i mean restarting the framework very often and be unusable most of the time. I can't reproduce all these situations, but I want only report this general fact so maybe you could considering to review the last versions' changes only. Thank you for your work!
The text was updated successfully, but these errors were encountered: