florisboard: OutOfMemory (OOM) Crash
This issue is a collection for all OOM (OutOfMemory) related crashes, as the number of duplicates regarding this topic is getting out-of-hand. Further crash reports with a stacktracte similar to the one attached below will be marked as duplicate and linked to this issue.
In general, these are the known areas in v0.3.10 which are most likely the sources of OOM crashes and which need fixing for v0.3.11 and beyond:
- Suggestions (Primary target for v0.3.12 development): The suggestions code’s memory management is not great and will be replaced soon by other, more efficient methods. It is planned that the new implementation is written in C++, which avoids unnecessary overhead of the JVM and thus the memory usage should be much lower.
- GlideTyping (Partially fixed since v0.3.11): The most relevant memory leak (and really big resource hog) has already been fixed in #625, smaller memory leaks of event listeners will be fixed later.
- Clipboard manager/history: Currently unknown severity, but it seems also here are some memory leaks.
- LayoutManager (Fixed since v0.3.11): The layout manager does a pretty good job at caching and preventing memory leaks, though the loading of layout json files can be improved to lower the stress on the CPU and to avoid potential garbage. See PR #734 for details.
- Re-initialization when rotating the screen (Partially fixed since v0.3.11): The re-initialization of the service class when rotating the screen has some pretty nasty memory leaks and thus over the time a lot of garbage accumulates which also leads to OOM errors.
- Settings UI: Even though this is a small memory leak and definitely not relevant considering the garbage the above areas accumulate, the Settings UI has some small memory leaks as well which should be fixed.
To help keep this thread clean, please do not post your OOM stacktrace in here or as a new issue. OOM stacktraces can be relevant but the app may crash in any place as soon as it has run out of RAM and by now I am aware of the biggest resource hogs in FlorisBoard. Should you have crash reports not involving a OOM stacktrace, you can of course submit a new issue!
java.lang.OutOfMemoryError: Failed to allocate a 24 byte allocation with 2027432 free bytes and 1979KB until OOM, target footprint 268435456, growth limit 268435456; failed due to fragmentation (largest possible contiguous allocation 24379392 bytes)
at kotlin.reflect.jvm.internal.KParameterImpl.getType(KParameterImpl.kt:43)
at kotlin.reflect.jvm.internal.KCallableImpl.callDefaultMethod$kotlin_reflection(KCallableImpl.kt:137)
at kotlin.reflect.jvm.internal.KCallableImpl.callBy(KCallableImpl.kt:112)
at com.squareup.moshi.kotlin.reflect.KotlinJsonAdapter.fromJson(KotlinJsonAdapter.kt:111)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.squareup.moshi.CollectionJsonAdapter.fromJson(CollectionJsonAdapter.java:81)
at com.squareup.moshi.CollectionJsonAdapter$2.fromJson(CollectionJsonAdapter.java:55)
at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
at com.squareup.moshi.CollectionJsonAdapter.fromJson(CollectionJsonAdapter.java:81)
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 34
- Comments: 35 (13 by maintainers)
As a long time user of your amazing app I am grateful that you put so much time into the app, listening to the community and squashing bugs like your life depends on it. Tysm
I’ve finally reached the stabilization phase of #734, which is a major rework of the layout engine and addresses core memory and performance issues (see https://github.com/florisboard/florisboard/pull/734#issuecomment-828101955 for details what is addressed and what not). If you want to try out the debug build, you can download it here. Be aware that the touch logic is still a bit wonky and that glide typing, gestures and emojis don’t work in the current debug build, which I will fix in the next two days. If you have feedback about the debug build, feel free to comment in #734! I will directly use it to improve the PR’s changes before merging into master.
Today evening v0.3.11 will release on stable track. This release marks an important milestone in restructuring the code base + logic of FlorisBoard’s text input, as well as fixing some critical parts for memory management and the by now infamous OOM errors. I’ve put a lot of work in this and hope that this will make FlorisBoard more usable for all users who experienced frequent OOM errors and crashes. I also want to thank @X-yl for his work on improving the glide typing code base and also fixing some other issues, @Glitchy-Tozier for the help in managing issues (especially for closing the vast amount of duplicates for this crash alone) and of course every one else who contributed either by participating in the issue discussions, creating/reviewing pull requests, translating FlorisBoard into their native language, etc. I really appreciate everyone in this awesome community 😃
Next week the development cycle for ~v0.3.12~ v0.3.13 will begin, where I will start setting up the JNI (Java Native Interface) in order to be able to write native C++ code directly. This is mostly needed for rewriting the suggestions and implementing autocorrect & spellchecking.
@patrickgold Great idea creating this Issue.
To save yourself some work, i suggest pinning it, that might help with the flood of issues. (You could do the same with the flashing keyboard issue but this one is even more potent)
@patrickgold thank you so much for working on this alot, have you thought of created an element or IRC group for us users to talk to you and hopefully give you more direct feedback?
Disabling suggestions won’t actually de-allocate the memory the dictionary needs, only after a service restart the effect is truly there (as the dictionary is not loaded initially). Of course, as soon as you disable suggestions the suggestions algorithm is not triggered, improving performance vastly thus.
Actually, scratch that. When you disable suggestions and the internal clipboard, all lag seems to be removed.
Just leaving a comment of my appreciation for this app. Features have been implemented at a really fast pace, and I’ll be patient waiting for upcoming fixes while I change some settings for now to mitigate the problem.
Hmm clipboard may be having a bigger impact than I expected. I will investigate and try to track down the memory leaks. Btw just to clarify, does it only happen if you copy and paste things (maybe lots of images or gifs?) or does it happen regardless?
@apjyotirmay you can also try to force stop the keyboard, that might help temporarily
Noob question: how do you know how much memory is used on phone? Do you have some kind of monitoring app installed?
Funny because I sometimes meet this issue in stable and had to switch to the debug version yesterday for the keyboard to show up. 🤣
Hey Patrick. Ive been having issues with the keyboard being stuck on screen today with the beta and it only had 80mb in use. I had to switch to the stable because I kept having issues with using andotp because they would time out on me and it was making me angry. 🤣