Appium java-client 8.6.0 caused a memory leak

[olezvinskyi]

Description

After I updated java-client 8.5.0 -> 8.6.0 I started facing memory lek (java.lang.OutOfMemoryError: Java heap space). I have a daily suite with a large number of tests (389 tests) and usually, it takes 3-4 hours to complete. In the previous version, everything worked fine but with 8.6.0 after 175-189 tests I got an exception about a memory leak.

Environment

• Java client build version or git revision if you use some snapshot: 8.6.0
• Appium server version or git revision if you use some snapshot: 2.1.3
• Desktop OS/version used to run Appium if necessary: MacOS Ventura 13.2
• Node.js version (unless using Appium.app|exe) or Appium CLI or Appium.app|exe: 16.14.2
• Mobile platform/version under test: iOS/Android
• Real device or emulator/simulator: emulator

Details

Java: 15 and 17 Gradle: 8.2.1 Selenide: 6.19.0 (which uses the latest appium java-client)

• Our Suite contains 389 tests and we run tests in parallel on 4 devices.
• We run tests through gradle: gradle clean runTest \

  gradle clean runTest \
  -Dandroid.useAndroidX=true \
  -Dandroid.enableJetifier=true \
  -Dorg.gradle.parallel=true \
  -Dmobile.os=android \
  -Dstore.rp.url.in.file=true \
  -Dorg.gradle.java.home=/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home \
  -Dudid="emulator-10889,emulator-16699,emulator-19332,emulator-21827" \
  -Dapp.path="/Users/serviceaccount/Apps/Android/Daily/tunein.apk" \
  -Dold.app.path="/Users/serviceaccount/Apps/oldBuilds/Android/tunein.apk" \
  -Dappium.start.retry.number=5 \
  -Dsuite=daily \
  -Dappium.use.prelaunched.server=false \
  -Drp.enable=true \
  -Drp.launch=ANDROID_Daily_Test_Run \
  -Delement.visible.timeout.seconds=10 \
  -Delement.wait.long.timeout.seconds=40 \
  -Dpage.ready.timeout.seconds=25 \
  -Delement.wait.very.short.timeout.seconds=6 \
  -Dappium.headless.mode=true \
  -Dappium.log.level=info \
  -Delement.wait.medium.timeout.seconds=20 \
  -Dcustom.wait.timeout.milliseconds=20000 \
  -Delement.wait.very.short.timeout.seconds=5 \
  -Dnew.command.timeout.seconds=120 \
  --info --configure-on-demand

Code To Reproduce Issue [ Good To Have ]

Code

• In our framework, we call waitUntilPageReady method every time we open a new page. Method waitUntilPageReady is implemented in each page class.
• Methods waitUntilPageReady contain initElements method which initialises elements

Exception Stacktraces

Exception

Link To Appium Logs

Appium Logs

[mykola-mokhnach]

Consider calling initElements once on page creation. I don't think it is a good idea to do it multiple times. I also need a heap dump

[olezvinskyi]

Consider calling initElements once on page creation. I don't think it is a good idea to do it multiple times. I also need a heap dump

I rerun my tests to generate a new heap dump and I will upload it here. But for now, I can attach a heap dump from old test run https://drive.google.com/file/d/1z30BIFhPi1de648FuCce5ElH90utuENs/view?usp=sharing

[mykola-mokhnach]

I have checked the above heap dump, and it looks fine to me. Nothing too suspicious. Try to get the dump when it actually crashes or close to it (You could use the https://www.baeldung.com/java-heap-dump-capture#automatically)

[olezvinskyi]

@mykola-mokhnach https://drive.google.com/file/d/1-Y-AZKdqjAC8G3HPU1-7I1Vc0yIGgspJ/view?usp=sharing fresh heap dump

[mykola-mokhnach]

• I can observe multiple aspectj instance occurrences, - check how it is used in your project
• Like I mentioned before, only call initElements once on page creation

[olezvinskyi]

• I think ReportPortal use AspectJ to catch @Step annotation during the test runtime. We set annotation @Step for each method to get informative reports. https://github.com/reportportal/client-java/wiki/Nested-steps

  
  task runTest(type: Test) {
  doFirst {
      def weaver = configurations.testRuntimeClasspath.find { it.name.contains("aspectjweaver") }
      jvmArgs += "-javaagent:$weaver"
  }
  systemProperties(System.getProperties())
  useTestNG {
      setConfigFailurePolicy("continue")
      testLogging.showStandardStreams = true
      useDefaultListeners = false
      Map<String, Object> variables = new HashMap<>()
      variables.putAll(getEnvironment())
      variables.putAll(getSystemProperties())
      def testGroups = variables.get("test.groups")
      def prTests = variables.get("pr.tests")
      suites 'src/test/resources/' + variables.get("mobile.os") + '/' + variables.get("suite") + '.xml'
      if (testGroups && !testGroups.empty) {
          def groups = testGroups.split(',')
          includeGroups groups
      }
      if (prTests && !prTests.empty) {
          def tests = prTests.replaceAll("\\s","").split(',')
          filter {
              for(test in tests) {
                  includeTestsMatching '*.' + test
              }
          }
      }
  }
  }

- We call initElements once we open a new page and create an instance of this page. 

But in 8.5.0 everything worked fine. 

[mykola-mokhnach]

I assume it might be some specific to your project setup. Try to profile it and check what data structures are using the most of the memory. Maybe I would be able to help when/if I know for sure which entities they reference and why, and if these entries are part of this library.

[olezvinskyi]

I removed PageFactory (initElements) approach and integrated Selenide into my framework. So for now I don't see java.lang.OutOfMemoryError