Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spring-native example fails to build with GraalVM 22 #12416

Open
super7ramp opened this issue Jul 21, 2024 · 7 comments
Open

spring-native example fails to build with GraalVM 22 #12416

super7ramp opened this issue Jul 21, 2024 · 7 comments
Assignees

Comments

@super7ramp
Copy link

spring-native example fails to build with GraalVM 22. It builds fine with GraalVM 21.

Errors found in build logs:

(...)
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.
(...)
Error: An object of type 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.
(...)
Error: An object of type 'io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.
(...)
Full logs
spring-native % ../gradlew nativeCompile
Picked up JAVA_TOOL_OPTIONS: 

> Task :opentelemetry-examples-spring-native:processAot
Picked up JAVA_TOOL_OPTIONS: 

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/

 :: Spring Boot ::                (v3.3.1)

2024-07-21T13:42:10.932+02:00  INFO 46353 --- [           main] i.o.example.graal.Application            : Starting Application using Java 21.0.1 with PID 46353 (/Users/57139H/dev/2-repos/opentelemetry-java-examples/spring-native/build/classes/java/main started by 57139H in /Users/57139H/dev/2-repos/opentelemetry-java-examples/spring-native)
2024-07-21T13:42:10.933+02:00  INFO 46353 --- [           main] i.o.example.graal.Application            : No active profile set, falling back to 1 default profile: "default"
2024-07-21T13:42:11.310+02:00  INFO 46353 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JDBC repositories in DEFAULT mode.
2024-07-21T13:42:11.317+02:00  INFO 46353 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 5 ms. Found 0 JDBC repository interfaces.

> Task :opentelemetry-examples-spring-native:generateResourcesConfigFile
[native-image-plugin] Resources configuration written into /Users/57139H/dev/2-repos/opentelemetry-java-examples/spring-native/build/native/generated/generateResourcesConfigFile/resource-config.json

> Task :opentelemetry-examples-spring-native:nativeCompile
[native-image-plugin] Quick build environment variable is set.
[native-image-plugin] GraalVM Toolchain detection is disabled
[native-image-plugin] GraalVM location read from environment variable: GRAALVM_HOME
[native-image-plugin] Native Image executable path: /Users/57139H/Library/Java/JavaVirtualMachines/graalvm-jdk-22.0.2/Contents/Home/lib/svm/bin/native-image
Warning: The option '-H:ResourceConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-core/tomcat-resource.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:ReflectionConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-core/tomcat-reflection.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:ReflectionConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-websocket/tomcat-reflection.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:ReflectionConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-el/tomcat-reflection.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:ResourceConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-el/tomcat-resource.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:ResourceConfigurationResources=META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-websocket/tomcat-resource.json' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: Please re-evaluate whether any experimental option is required, and either remove or unlock it. The build output lists all active experimental options, including where they come from and possible alternatives. If you think an experimental option should be considered as stable, please file an issue.
========================================================================================================================
GraalVM Native Image: Generating 'opentelemetry-examples-spring-native' (shared library)...
========================================================================================================================
For detailed information and explanations on the build output, visit:
https://github.com/oracle/graal/blob/master/docs/reference-manual/native-image/BuildOutput.md
------------------------------------------------------------------------------------------------------------------------
[1/8] Initializing...                                                                                    (5,2s @ 0,18GB)
 Java version: 22.0.2+9, vendor version: Oracle GraalVM 22.0.2+9.1
 Graal compiler: optimization level: b, target machine: armv8-a, PGO: off
 C compiler: cc (apple, arm64, 15.0.0)
 Garbage collector: Serial GC (max heap size: 80% of RAM)
 2 user-specific feature(s):
 - com.oracle.svm.thirdparty.gson.GsonFeature
 - org.springframework.aot.nativex.feature.PreComputeFieldFeature
------------------------------------------------------------------------------------------------------------------------
 2 experimental option(s) unlocked:
 - '-H:ResourceConfigurationResources': Use a resource-config.json in your META-INF/native-image/<groupID>/<artifactID> directory instead. (origin(s): 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-websocket/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-websocket/10.1.25/efd7848a9677e9a7cf8367b43213805eca70805/tomcat-embed-websocket-10.1.25.jar', 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-core/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-core/10.1.25/c1e5ee12f537e6b4fea2b98a7160dcf0db610561/tomcat-embed-core-10.1.25.jar', 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-el/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-el/10.1.25/2f030e4971e29245c10e58723fb6b364ce23933b/tomcat-embed-el-10.1.25.jar')
 - '-H:ReflectionConfigurationResources': Use a reflect-config.json in your META-INF/native-image/<groupID>/<artifactID> directory instead. (origin(s): 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-websocket/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-websocket/10.1.25/efd7848a9677e9a7cf8367b43213805eca70805/tomcat-embed-websocket-10.1.25.jar', 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-core/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-core/10.1.25/c1e5ee12f537e6b4fea2b98a7160dcf0db610561/tomcat-embed-core-10.1.25.jar', 'META-INF/native-image/org.apache.tomcat.embed/tomcat-embed-el/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-el/10.1.25/2f030e4971e29245c10e58723fb6b364ce23933b/tomcat-embed-el-10.1.25.jar')
------------------------------------------------------------------------------------------------------------------------
Build resources:
 - 18,14GB of memory (75,6% of 24,00GB system memory, determined at start)
 - 8 thread(s) (100,0% of 8 available processor(s), determined at start)
SLF4J(W): No SLF4J providers were found.
SLF4J(W): Defaulting to no-operation (NOP) logger implementation
SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further details.
[2/8] Performing analysis...  [*****]                                                                   (30,1s @ 2,23GB)
   25 281 reachable types   (90,3% of   27 991 total)
   38 766 reachable fields  (61,5% of   63 063 total)
  130 816 reachable methods (65,9% of  198 538 total)
    8 555 types,   862 fields, and 9 724 methods registered for reflection
       66 types,    72 fields, and    57 methods registered for JNI access
        5 native libraries: -framework CoreServices, -framework Foundation, dl, pthread, z

Error: Unsupported features in 10 methods
Detailed message:
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.
------------------------------------------------------------------------------------------------------------------------

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add 

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with 

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.CODE_FILEPATH
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add 

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with 

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.CODE_FUNCTION
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add 

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with 

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.CODE_LINENO
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add 

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with 

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.CODE_NAMESPACE
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add 

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with 

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.LOG_MARKER
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add 

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with 

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.THREAD_ID
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' are persisted in the image heap, add 

    '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.api.internal.InternalAttributeKeyImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=io.opentelemetry.api.internal.InternalAttributeKeyImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with 

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.api.internal.InternalAttributeKeyImpl' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.THREAD_NAME
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' are persisted in the image heap, add 

    '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with 

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.attributeKeys
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' are persisted in the image heap, add 

    '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with 

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

                        3,2s (8,7% of total time) in 584 GCs | Peak RSS: 2,84GBIf you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
 | CPU load: 6,19
To fix this, include '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.
========================================================================================================================

Failed generating 'opentelemetry-examples-spring-native' after 35,9sThe following detailed trace displays from which field in the code the object was reached.
.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.mdcAttributeKeys
    at <unknown-location>
  registered as read because: null
Error: An object of type 'io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue' are persisted in the image heap, add 

    '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with 

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap$DiscardingQueue' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  reading static field io.opentelemetry.instrumentation.api.internal.cache.concurrentlinkedhashmap.ConcurrentLinkedHashMap.DISCARDING_QUEUE
    at <unknown-location>
  registered as read because: null


> Task :opentelemetry-examples-spring-native:nativeCompile FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':opentelemetry-examples-spring-native:nativeCompile'.
> Process 'command '/Users/57139H/Library/Java/JavaVirtualMachines/graalvm-jdk-22.0.2/Contents/Home/bin/native-image'' finished with non-zero exit value 1

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.9/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD FAILED in 45s
9 actionable tasks: 5 executed, 1 from cache, 3 up-to-date
WARNING: The following functionality has been deprecated and will be removed in the next major release of the Develocity Gradle plugin. Run with '-Ddevelocity.deprecation.captureOrigin=true' to see where the deprecated functionality is being used. For assistance with migration, see https://gradle.com/help/gradle-plugin-develocity-migration.
- The deprecated "gradleEnterprise.server" API has been replaced by "develocity.server"
- The deprecated "gradleEnterprise.buildScan.uploadInBackground" API has been replaced by "develocity.buildScan.uploadInBackground"
- The deprecated "gradleEnterprise.buildScan.publishAlwaysIf(condition)" API has been replaced by "develocity.buildScan.publishing.onlyIf { condition }"
- The deprecated "gradleEnterprise.buildScan.capture.taskInputFiles" API has been replaced by "develocity.buildScan.capture.fileFingerprints"
- The "com.gradle.enterprise" plugin has been replaced by "com.gradle.develocity"
spring-native %

Adding --trace-object-instantiation=io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache as suggested in the logs gives:

The culprit object has been instantiated by the 'io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper' class initializer with the following trace:
        at io.opentelemetry.instrumentation.api.internal.cache.MapBackedCache.<init>(MapBackedCache.java:16)
        at io.opentelemetry.instrumentation.api.internal.cache.Cache.bounded(Cache.java:38)
        at io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper.<clinit>(LoggingEventMapper.java:51)

Adding --initialize-at-run-time=io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper gives:

Error: Incompatible change of initialization policy for io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper: trying to change RUN_TIME from 'META-INF/native-image/io.opentelemetry/opentelemetry-examples-spring-native/native-image.properties' in 'file:///Users/57139H/dev/2-repos/opentelemetry-java-examples/spring-native/build/libs/opentelemetry-examples-spring-native-0.1.0-SNAPSHOT-plain.jar' with 'io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper' to BUILD_TIME from 'META-INF/native-image/io.opentelemetry.instrumentation/opentelemetry-logback-appender-1.0/native-image.properties' in 'file:///Users/57139H/.gradle/caches/modules-2/files-2.1/io.opentelemetry.instrumentation/opentelemetry-logback-appender-1.0/2.5.0-alpha/97b4682432fb4295b075707a8bf38da8e7caeea4/opentelemetry-logback-appender-1.0-2.5.0-alpha.jar' with 'io.opentelemetry.instrumentation.logback.appender.v1_0.internal.LoggingEventMapper'

Excluding native configuration with the following arguments makes the build pass but I'm not sure it's the right thing to do:

--exclude-config .*opentelemetry-logback-appender.*\.jar .*native-image\.properties \
--exclude-config .*opentelemetry-instrumentation-api.*\.jar .*native-image\.properties
@jurgis-sipols
Copy link

I stumbled upon this issue as well. It doesn't feel right to tune build process by having --initialize-at-build-time=x.y.x.package (solution from my codebase) or --exclude-config as the author pointed out.

any updates on this one? ETA?

@jurgis-sipols
Copy link

@super7ramp maybe this ticket should be reported in different repo of the OTEL. This repo is just for the examples and maybe it doesn't have the traction and the attention.

@kyryllparolys
Copy link

@super7ramp could you please provide a link to the GraalVM you've used to successfully build this?

@jurgis-sipols
Copy link

@jack-berg could this problem be related to the open-telemetry/opentelemetry-java#6127 and similar solution as open-telemetry/opentelemetry-java#6139 could be applied for the java instrumentation https://github.com/open-telemetry/opentelemetry-java-instrumentation?

@trask
Copy link
Member

trask commented Oct 8, 2024

cc @jeanbisutti

@trask
Copy link
Member

trask commented Oct 8, 2024

transferring to instrumentation repo at @jeanbisutti's request

@trask trask transferred this issue from open-telemetry/opentelemetry-java-examples Oct 8, 2024
@jeanbisutti jeanbisutti self-assigned this Oct 8, 2024
@jeanbisutti
Copy link
Member

@super7ramp Thank you for reporting this issue. We need to do changes in the OpenTelemetry starter to make it work without any user configuration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants