AndroidIDEOfficial / AndroidIDE

AndroidIDE is an IDE for Android to develop full featured Android apps.
https://m.androidide.com
GNU General Public License v3.0
2.08k stars 245 forks source link

[Bug]: The max heap space is stuck at 712 MBs, preventing compilation #1807

Closed Rafael2616 closed 1 month ago

Rafael2616 commented 1 month ago

Issue Checklist

Additional terms

Issue explanation

After commit https://github.com/AndroidIDEOfficial/AndroidIDE/actions/runs/8363217788 'xmx' configuration used to build the project is 712 MBs instead of the one defined in gradle.properties, preventing the execution of certain tasks and the build

Expected behavior

Recognize the value of xmx from org.gradle.jvmargs to that defined in the project's Gradle properties file instead of 712 MBs.

Version name

Version : v2.7.1-beta (27101) CI Build : true Branch : dev Commit : b7e8464d5 Variant : armeabi-v7a (release) Build type : OFFICIAL F-Droid Build : false F-Droid Version : null F-Droid Version code : -1 SDK Version : 28 Supported ABIs : [armeabi-v7a, armeabi] Manufacturer : LGE Device : LM-X420

Download source

GitHub

Relevant log output

> Task :app:mergeExtDexDebug
> Task :app:mergeLibDexDebug

The Daemon will expire after the build after running out of JVM heap space.
The project memory settings are likely not configured or are configured to an insufficient value.
The daemon will restart for the next build, which may increase subsequent build times.
These settings can be adjusted by setting 'org.gradle.jvmargs' in 'gradle.properties'.
The currently configured max heap space is '712 MiB' and the configured max metaspace is 'unknown'.
For more information on how to set these values, please refer to https://docs.gradle.org/8.6/userguide/build_environment.html#sec:configuring_jvm_memory in the Gradle documentation.
To disable this warning, set 'org.gradle.daemon.performance.disable-logging=true'.
Daemon will be stopped at the end of the build after running out of JVM heap space
itsaky commented 1 month ago

The mentioned commit uses addJvmArguments to specify arguments for the Java VM, which, for some reason, resets the Xmx value for the daemon. The Gradle Daemon docs mentions :

Daemons use the JVM’s default minimum heap size.

And from the JVM 17 docs :

Maximum heap size of 1/4 of physical memory

I have added a commit which should fix the issue (works in my tests at least). Can you retry with the latest CI build?

Rafael2616 commented 1 month ago

Got it, I'll test and check if the error has been fixed 👍

Rafael2616 commented 1 month ago

Ok, I don't know if this is related to the last commit, as the version I was using before upgrading to this is one from about 3 months ago, but when trying to initialize my multi-module project the app starts to freeze and becomes unusable (it didn't happen in the commit I was using) This happens right after the project has been successfully initialized.

Video:

https://drive.google.com/file/d/1KZ_eFy9RAxDMaRljVQX7NcdmcmyI9kec/view?usp=drivesdk

Rafael2616 commented 1 month ago

After some time stuttering, the IDE shows the crash log:

AndroidIDE Crash Report
Version : v2.7.1-beta (27101)
CI Build : true
Branch : dev
Commit : b7e8464d5
Variant : armeabi-v7a (release)
Build type : OFFICIAL
F-Droid Build : false
F-Droid Version : null
F-Droid Version code : -1
SDK Version : 28
Supported ABIs : [armeabi-v7a, armeabi]
Manufacturer : LGE
Device : LM-X420

Stacktrace:
java.lang.OutOfMemoryError: Failed to allocate a 24 byte allocation with 0 free bytes and 0B until OOM, max allowed footprint 268435456, growth limit 268435456
    at java.lang.StringFactory.newStringFromChars(StringFactory.java:267)
    at org.kxml2.io.KXmlParser.readValue(KXmlParser.java:1451)
    at org.kxml2.io.KXmlParser.parseStartTag(KXmlParser.java:1137)
    at org.kxml2.io.KXmlParser.next(KXmlParser.java:380)
    at org.kxml2.io.KXmlParser.next(KXmlParser.java:321)
    at com.itsaky.androidide.xml.internal.versions.DefaultApiVersionsRegistry.readTag(Unknown Source:125)
    at com.itsaky.androidide.xml.internal.versions.DefaultApiVersionsRegistry.readApiVersions(Unknown Source:36)
    at com.itsaky.androidide.xml.internal.versions.DefaultApiVersionsRegistry.forPlatformDir(Unknown Source:109)
    at com.itsaky.androidide.projects.api.AndroidModule.getApiVersions(Unknown Source:37)
    at com.itsaky.androidide.projects.api.AndroidModule$readResources$2$resourceFlow$1.invokeSuspend(Unknown Source:121)
    at com.itsaky.androidide.projects.api.AndroidModule$readResources$2$resourceFlow$1.invoke(Unknown Source:12)
    at kotlinx.coroutines.flow.SafeFlow.collect(Unknown Source:125)
    at com.itsaky.androidide.projects.ProjectManagerImpl$setupProject$lambda$2$$inlined$map$1.collect(Unknown Source:17)
    at kotlinx.coroutines.flow.FlowKt.toCollection(Unknown Source:61)
    at com.itsaky.androidide.projects.api.AndroidModule.readResources(Unknown Source:154)
    at com.itsaky.androidide.projects.ProjectManagerImpl$setupProject$4$jobs$1$1.invokeSuspend(Unknown Source:289)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(Unknown Source:8)
    at kotlinx.coroutines.DispatchedTask.run(Unknown Source:120)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(Unknown Source:95)

This didn't happen in the version from 3 months ago that I used before upgrading to this one, but when I downgraded again to the version I used (and that worked) the error starts to happen there too.. Could it be due to some configuration that is persisted even after the downgrade?

Rafael2616 commented 1 month ago

After some days of testing, I reinstalled the IDE from scratch, cleaned the IDE data and Gradle caches, but the crash problem continued even after all this. So after I need to open my project sometimes without any hope just to access some files, the project iinitialized successfully and from then on for about 2 days every time it continued to initialize as if sitting had occurred But today it started to happen again and thanks to the new implementation of the memory graph, I noticed this pattern in the following video. IDE memory consumption scales quickly after project initialization, in the configuration phase of project "I believe"

https://drive.google.com/file/d/174I8TfgfLO-tHxO6A3RuVFX1i-Y4Yefv/view?usp=drivesdk

And the original problem of this Issue has actually been fixed. So I think I can move this to another problem?

itsaky commented 1 month ago

And the original problem of this Issue has actually been fixed. So I think I can move this to another problem?

Sure. Memory issues could be discussed in #1694.