Cannot allocate memory #1504
Comments
|
It is possible this is related to WSL 1, upgrade to WSL 2 |
|
I had similar 'Cannot allocate memory' issue. In xxxxxxxxxxxxxxxxxx there was one of following files, randomly: I spend two days to figure out how to solve it, and in my case it was because of openjdk-17-jdk. I checked it with following environments with no success on two separate laptops: My Kivy project with virtual environment base on Python 3.8. I tried clean Ubuntu installations, new Kivy projects, old projects which was previously working with Buildozer 1.2.0, removing .buildozer folder from project dir, upgrading gradle from 7.4.1 to 7.4.2, change memory settings (GRADLE_OPTS, JAVA_OPTS), a lot of wasted time. I tried to build with: and Strange, that from time to time I was able to build aab package, but never apk, setting following param of buildozer.spec: When this line was commented out aab file was able to build, but not always, sometimes 'Cannot allocate memory' also occured but not too often. Then I started to thinking that this may happen because of Java 17. I wasn't able to uninstall it completely using: Java 17 was still present and it was default one in the path. I'm not an Ubuntu expert, I have no clue why Java 17 was still available. and 17 was still available. Strange. So I uninstalled Ubuntu, installed it again from Microsoft Store, set to WSL v1 using: then installed all Buildozer required components, but with Java 11 instead of 17, based on pages mentioned above: And yes, now apk build process works like a charm. Afterwards, I also faced with another build issue: building with: I solved it by following line change of buildozer.spec: But it wasn't also easy, as long I realized that there is probably a Buildozer bug. Buildozer does not always update targetSdkVersion according to android.api param change. https://stackoverflow.com/questions/72746288/buildozer-android-api-doesnt-change/74311692#74311692 So in my case it wasn't WSL version related issue. It worked same on v1 and v2. And it was not Ubuntu version related issue as well. |
|
Thanks for the info on jdk17 and Gradle.
FYI https://github.com/Android-for-Python/Android-for-Python-Users#changing-buildozerspec Also FYI https://github.com/Android-for-Python/Android-for-Python-Users#androidapi |
Thanks. I wasn't aware of this. I was thinking that buildozer.spec is read and apply on every build. I changed other values in the past and it was always applied into apk. I never used buildozer appclean. buildozer appclean in fact removes whole .buildozer folder! It causes that whole environment have to be redownloaded and compiled which is really long running process. It make no sense to do it for tiny change like android.api value. In my opinion it would be better to read and apply all parameters from buildozer.spec on every buildozer -v android release and buildozer -v android debug by default to avoid suprises. |
|
👋 @AriDeve, we use the issue tracker exclusively for bug reports and feature requests. However, this issue appears to be a support request. Please use our support channels to get help with the project. |
|
Just for update: this case is still valid for latest Kivy 2.3.0, Buildozer 1.5.0, and Ubuntu 20.04.6 and 22.04.3 running on WSL v1 and v2. Install OpenJDK 11 on Ubuntu by running: Make OpenJDK 11 as default Java by running: |
|
FYI I do not see the same issue - I don't know why my experience is different. How much physical memory does the computer have? Because you use an old Windows version, I'd wonder if you are using old hardware with insufficient physical memory for this task. So I'd look at the WSL process memory (see below), the default is going to depend on the Windows physical memory. It is possible to change the WSL process memory (see below) but if there is insufficient physical memory this won't help. Similarly for the Java heap size. I'm not involved with development here, just a user driving by. I use: Windows 11 My .wslconfig is not the default for reasons unrelated to Buildozer/p4a . My Ubuntu meminfo starts with |
|
Hi @RobertFlatt. My second PC have got same Windows and 8GB RAM. I verified memory usage both on Windows and Ubuntu using top command during Buildozer build and seems there is no insufficient memory issue at all. What exact Ubuntu are you using? Can you share your: Can you check your OpenJDK version under Ubuntu? I will try on my third PC which is running Windows 11. I'm testing on very simple "hello world" Kivy app, just created, I reinstalled Ubuntu several times, so it's clean. I also tried to downgrade Buildozer to 1.4.0, it doesn't help, seems this is not Buildozer related issue. It's something related to Gradle and JDK 17 on WSL. Same happens with gradle 7.4.1 which was used by previous python-for-android before this commit kivy/python-for-android#2887, and current Gradle 8.0.2, which is no longer compatible with JDK 11, but I requested to downgrade it to latest 7.x here kivy/python-for-android#3000. I also tried to specify and increase heap size for Gradle within gradlew shell script located within project's .buildozer\android\platform\build-armeabi-v7a\dists\poject_name\ folder - nothing works, still Cannot allocate memory executing file copy in Gradle mergeReleaseJniLibFolders task. It happens usually for libffi.so or libssl1.1.so. I found similar issues related to WSL and Flutter. It's related to something called dart which probably is not used by Kivy/Buildozer/p4a: https://stackoverflow.com/questions/64268257/flutter-build-fails-on-wsl2-with-filesystemexception-os-error-cannot-allocate Knowing that there is at least one person in the world, who is able to build Kivy apk on WSL, I mean you :) I will try to reinstall Ubuntu using WSL v2 on Windows 11, then create fresh new, simple project base on Kivy 2.3.0, Buildozer 1.5.0 with JDK 17, then will share results with you. |
|
WSL2 is a common platform for Buildozer users. WSL1 has had issues, for example https://github.com/Android-for-Python/Android-for-Python-Users?tab=readme-ov-file#c-compiler-cannot-create-executables and https://github.com/Android-for-Python/Android-for-Python-Users?tab=readme-ov-file#usrbingzip-1-elf--not-found Don't use WSL1. Do not build on the Windows file system. This may give unpredictable results with some Python packages, and builds that are five to ten times slower than on the Linux partition. https://github.com/Android-for-Python/Android-for-Python-Users?tab=readme-ov-file#install Don't waste your time on the Windows machine with 8GB of physical memory, my guess, there is probably not enough memory left for Gradle on WSL. Yes Gradle appears to use more memory with Java 17 (unknown by me if this is due to change in Gradle or Java). This is usually only a problem with apps that are too big for the Android Store, Hello World is NOT an example of "too big". https://github.com/Android-for-Python/Android-for-Python-Users?tab=readme-ov-file#javalangoutofmemoryerror . See comments there about adjusting heap size. Note the comment about rebooting, Gradle can leak heap memory when it fails outofmemory - causing following builds to fail with the same symptom but a potentially incorrectly. Gradle is a tool supplied with Google's Android build tools, so any tool set that builds for Android devices potentially shows this issue. Since Gradle is somebody else's software and mostly 'just works' I don't expect you'll find a lot of detailed knowledge here. Best guess this issue is something site specific. I don't use an emulator, you could use the emulator in Android Studio on Windows https://github.com/Android-for-Python/Android-for-Python-Users?tab=readme-ov-file#appendix-b--using-an-emulator I don't think the issue is fine tuning versions, but in answer to your question. As I said previously
So I don't have any suggestions for you, except heap size, which by default depends on process memory size, which by default depends on physical memory. I'd also check for package interaction, try (I've no idea why that repeats itself). As I said earlier I'm driving by, I've got my own journey, so now moving on. Good luck in your quest. |
I cannot fully agree. There are pros and cons, and in my opinion there are more pros over cons regarding WSL v1. Issue no1 https://github.com/Android-for-Python/Android-for-Python-Users?tab=readme-ov-file#c-compiler-cannot-create-executables I was building three Kivy projects last three years with group of five childrens using Kivy 2.0.0, then 2.1.0. All had their own laptops running Windows 10 or 11. We were learning Python and Kivy. All were using Python 3.8, PyCharm CE, Ubuntu 18, 20 or 22 with WSL v1 and Nox as Android Emulator for debugging and testing. Some setups were equipped with 8GB RAM and everything was working. It was painfull at some moments, there were challenges because of different Windows security setups, different antivirus software, access rights, human mistakes, remote learning and so on, but finally Kivy was able to build with success for each of them. WSL v1 was choosen because of severs meaningful pros, which are described here:
We were using PCs with 8GB of RAM running PyCharm, Ubuntu on WSL v1 and Nox at the same time, with successfull Buildozer builds, really.
Gradle doesn't throw java.lang.OutOfMemoryError in my case. There is no java crash report, it looks different. At first sight I was thinking it is related to write permissions or too long path, but it's not. I can write, copy to same path where Gradle is trying to copy so files, but somehow Gradle can't, failing on random so file. Also knowing that java.nio.file.FileSystemException throws an
Yeap, It's hard nut to crack, but I won't give up without a fight :)
I heard about it, but when I was searching for something that childrens can handle, relatively small, easy to use, with similar look and feel like real Android device, I decided to use Nox.
Thanks. I'm currently installing same setup on my laptop running on Win 11.
It's not repeating. First two rows are for JDK, rest are for JRE :)
Many thanks for huge piece of knowledge. I'll try to find solution for WSL v1. Update: I've just build apk using my laptop running Windows 11 Pro 22H2 x64, Python 3.8.10, Ubuntu 22.04 (WSL v2), Kivy 2.3.0, Buildozer 1.5.0, Gradle 8.0.2 and JDK 17. Laptop is equipped with 8GB RAM, while Ubuntu had 4GB total memory. Project was located on Windows partition and first build was very time consuming, but I don't know if it was because of WSL v2 slow I/O for mounted Windows partition or maybe because this hardware is just slower compared to my desktop setup running Windows 10. Maybe I will retry it with WSL v1 on same laptop to see difference between first build, same project, located on Windows partition, on same hardware with WSL v1 and v2. |
Versions
Description
buildozer -v android debugrunning into a problem with the gradle build, it throws errors and never completes. All the errors it throws are about memory, for example:.buildozer/android/platform/build-arm64-v8a_armeabi-v7a/dists/myapp/build/intermediates/merged_jni_libs/debug/out/arm64-v8a/libhidapi.so: Cannot allocate memoryHow would one solve this issue, as I haven't found a way to increase the allocated memory, and cannot think of any other solutions?
The text was updated successfully, but these errors were encountered: