RFR: 8341024: [test] build/AbsPathsInImage.java fails with OOM when using ubsan-enabled binaries

Erik Joelsson erikj at openjdk.org
Fri Sep 27 12:30:39 UTC 2024


On Fri, 27 Sep 2024 10:05:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The jtreg test build/AbsPathsInImage.java fails with OOM when using ubsan-enabled binaries (on Linux x86_64).
> Reason seems to be that the ubsan-enabled binaries are much larger than 'normal' product binaries.
> (for debug binaries the test is already disabled)
> Error is :
> java.lang.OutOfMemoryError: Java heap space
> at java.base/java.nio.file.Files.read(Files.java:3242)
> at java.base/java.nio.file.Files.readAllBytes(Files.java:3299)
> at AbsPathsInImage.scanFile(AbsPathsInImage.java:181)
> at AbsPathsInImage$1.visitFile(AbsPathsInImage.java:173)
> at AbsPathsInImage$1.visitFile(AbsPathsInImage.java:153)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2810)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2881)
> at AbsPathsInImage.scanFiles(AbsPathsInImage.java:153)
> at AbsPathsInImage.main(AbsPathsInImage.java:119)
> at java.base/java.lang.invoke.LambdaForm$DMH/0x00007fb6087003a8.invokeStatic(LambdaForm$DMH)
> at java.base/java.lang.invoke.LambdaForm$MH/0x00007fb608a2f3d8.invoke(LambdaForm$MH)
> at java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:154)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> at java.base/java.lang.Thread.runWith(Thread.java:1589)
> at java.base/java.lang.Thread.run(Thread.java:1576)
> 
> Especially the debuginfo file for libjvm.so gets HUGE, and needs a higher Xmx setting for this test.
> 
> At some later point in time, the test could be rewritten to use less memory when looking into the JDK image files.

I took a quick look at why I chose to read the full files into memory instead of reading from a stream, and while that could be fixed, at least at first glance it seemed to get rather complicated. This seems like a pretty simple and quick workaround.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21217#pullrequestreview-2333599298


More information about the build-dev mailing list