[🐛 Bug]: Selenium 4.26.0 has memory leak.

shinobi01 commented 4 days ago

What happened?

I'm using Java + Cucumber + testNG + Appium to do automation test on mobile devices. I got some errors as following Caused by: java.lang.OutOfMemoryError: Compressed class space So I checked with VisualVM, the Metaspace and Classes are always increasing.

The loaded classs are not unloaded. After downgrade to 4.23.0, this issue is gone

How can we reproduce the issue?

Sorry I can't share my code, but create a cucumber test cases and rerun it several times should be able to reproduce.

Relevant log output

Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
Exception in provider
org.apache.maven.surefire.booter.SurefireExecutionException: Exception in provider
    at org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:91)
    at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1144)
    at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
    at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:906)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:206)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
    at java.base/java.lang.reflect.Method.invoke(Method.java:580)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:361)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:314)
    at org.codehaus.classworlds.Launcher.main(Launcher.java:41)
Caused by: java.lang.OutOfMemoryError: Compressed class space

Operating System

macos 14.4.1

Selenium version

Java 17 + Java-Client 9.3.0 (Selenium 4.26.0)

What are the browser(s) and version(s) where you see this issue?

Android and iOS

What are the browser driver(s) and version(s) where you see this issue?

None

Are you using Selenium Grid?

None

github-actions[bot] commented 4 days ago

@shinobi01, thank you for creating this issue. We will troubleshoot it as soon as we can.

Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

joerg1985 commented 3 days ago

@shinobi01 could you share a histogram of your memory dump? The easiest way is to call jmap -histo {pid}

It would be helpful to know the exact version when it did break. Thanks in advance

shinobi01 commented 3 days ago

@joerg1985 This is the log running on Linux jenkins slave. hs_err_pid51968.log The first time I have this error is on September, but the reproduce rate is not frequently. But on 4.26.0, it is 100% reproduce.

joerg1985 commented 3 days ago

@shinobi01 this crash dump does not contain the infos i need, the output should look like this

shinobi01 commented 3 days ago

Test start jmap.txt 5 minutes later jmap2.txt

joerg1985 commented 2 days ago

@shinobi01 are you using the WebDriverDecorator? I think i could reproduce the root issue, each invocation does return a new class. Are you intentionally keeping hunderts references to WebElements found? Each WebElement brings it's own class definition, due to the Proxy and this could kill your class space.

This is a extension to the DecoratedWebDriverTest to reproduce the issue.


  @Test
  void doesNotCreateTooManyClasses() {
    final WebElement found = mock(WebElement.class);
    Function<WebDriver, WebElement> f = $ -> $.findElement(By.id("test"));
    Fixture fixture = new Fixture();
    when(f.apply(fixture.original)).thenReturn(found);

    WebElement proxy1 = f.apply(fixture.decorated);
    WebElement proxy2 = f.apply(fixture.decorated);
    WebElement proxy3 = f.apply(fixture.decorated);

    assertThat(proxy1.getClass()).isSameAs(proxy2.getClass());
    assertThat(proxy1.getClass()).isSameAs(proxy3.getClass());
  }

shinobi01 commented 2 days ago

@joerg1985 sorry, i have no idea about WebDriverDecorator, i started the webdriver by using selenide appium.

joerg1985 commented 12 hours ago

This might be related to https://github.com/appium/java-client/issues/2119 but in any case the WebDriverDercorator does create to mutch classes without the PR above.

SeleniumHQ / selenium