Build fails by "Error: No instances of java.io.FilePermission are allowed in the image heap as this class should be initialized at image runtime."
Describe GraalVM and your environment :
- GraalVM version or commit id if built from source: 35b2ed8050709685030cb9b1ac1082f474d1cb13
- CE or EE: CE
- JDK version: JDK11
- OS and OS Version: Linux 3.10.0-514
- Architecture: amd64
- The output of
java -Xinternalversion: OpenJDK 64-Bit Server VM (11.0.6+9-jvmci-20.0-b02) for linux-amd64 JRE (11.0.6+9-jvmci-20.0-b02), built on Jan 20 2020 20:06:41 by "buildslave" with gcc 7.3.0
Building polyglot.image... [dependencies updated: LAUNCHER_COMMON, GRAALVM_N1_CE_JAVA11_ATS_COV_GU_GVM_INS_LSP_MJDKSL_PRO_PYN_PYNL_SLG_SVML_VVM]
env MX__SUITEMODEL=sibling MX_PRIMARY_SUITE_PATH=/home/ryuta/packages/graal/graal/vm MX_SUBPROCESS_COMMAND_FILE=/tmp/mx_subprocess_command.YAYQrj MX_HOME=/home/ryuta/packages/graal/mx \
/home/ryuta/packages/graal/graal/sdk/mxbuild/linux-amd64/GRAALVM_N1_CE_JAVA11_ATS_COV_GU_GVM_INS_LSP_MJDKSL_PRO_PYN_PYNL_SLG_SVML_VVM/graalvm-n1-ce-java11-20.1.0-dev/lib/svm/bin/native-image --macro:polyglot-launcher -H:NumberOfThreads=1 --macro:truffle --language:all -H:Path=/home/ryuta/packages/graal/graal/sdk/mxbuild/linux-amd64/polyglot.image
[polyglot:10047] classlist: 9,698.57 ms, 1.68 GB
[polyglot:10047] (cap): 1,004.17 ms, 1.68 GB
[polyglot:10047] setup: 2,453.68 ms, 1.68 GB
[polyglot:10047] (typeflow): 662,902.80 ms, 12.94 GB
[polyglot:10047] (objects): 1,375,133.06 ms, 12.94 GB
[polyglot:10047] (features): 22,273.18 ms, 12.94 GB
[polyglot:10047] analysis: 2,068,496.44 ms, 12.94 GB
Error: No instances of java.io.FilePermission are allowed in the image heap as this class should be initialized at image runtime. To see how this object got instantiated use -H:+TraceClassInitialization.
Detailed message:
Trace: Object was reached by
reading field java.util.concurrent.ConcurrentHashMap$Node.val of
constant java.util.concurrent.ConcurrentHashMap$Node@4d40892f reached by
indexing into array
constant java.util.concurrent.ConcurrentHashMap$Node[]@643518ee reached by
reading field java.util.concurrent.ConcurrentHashMap.table of
constant java.util.concurrent.ConcurrentHashMap@4d40892f reached by
reading field java.io.FilePermissionCollection.perms of
constant java.io.FilePermissionCollection@7d0a4108 reached by
reading field java.util.concurrent.ConcurrentHashMap$Node.val of
constant java.util.concurrent.ConcurrentHashMap$Node@360907a reached by
indexing into array
constant java.util.concurrent.ConcurrentHashMap$Node[]@75fb2d9e reached by
reading field java.util.concurrent.ConcurrentHashMap.table of
constant java.util.concurrent.ConcurrentHashMap@360907a reached by
reading field java.security.Permissions.permsMap of
constant java.security.Permissions@6ba6f979 reached by
reading field java.security.ProtectionDomain.permissions of
constant java.security.ProtectionDomain@6d661151 reached by
indexing into array
constant java.security.ProtectionDomain[]@26324c3e reached by
reading field java.security.AccessControlContext.context of
constant java.security.AccessControlContext@120f1761 reached by
reading field java.net.URLClassLoader.acc of
constant java.net.URLClassLoader@45058fad reached by
reading field java.lang.Class.classLoader of
constant java.lang.Class@6419f09e reached by
Hub
Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
Error: Image build request failed with exit status 1
[exit code: 1]
File "/home/ryuta/packages/graal/mx/mx.py", line 19437, in <module>
main()
File "/home/ryuta/packages/graal/mx/mx.py", line 19418, in main
retcode = c(command_args)
File "/home/ryuta/packages/graal/mx/mx_commands.py", line 147, in __call__
return self.command_function(*args, **kwargs)
File "/home/ryuta/packages/graal/graal/substratevm/mx.substratevm/mx_substratevm.py", line 1357, in build
orig_command_build(args, vm)
File "/home/ryuta/packages/graal/mx/mx_commands.py", line 147, in __call__
return self.command_function(*args, **kwargs)
File "/home/ryuta/packages/graal/mx/mx.py", line 13655, in build
task.proc.start()
File "/usr/lib64/python2.7/multiprocessing/process.py", line 130, in start
self._popen = Popen(self)
File "/usr/lib64/python2.7/multiprocessing/forking.py", line 126, in __init__
code = process_obj._bootstrap()
File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in _bootstrap
self.run()
File "/usr/lib64/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "/home/ryuta/packages/graal/mx/mx.py", line 13636, in executeTask
task.execute()
File "/home/ryuta/packages/graal/mx/mx.py", line 4701, in execute
_built = self.build()
File "/home/ryuta/packages/graal/graal/sdk/mx.sdk/mx_sdk_vm_impl.py", line 1814, in build
self.svm_support.native_image(build_args, output_file)
File "/home/ryuta/packages/graal/graal/sdk/mx.sdk/mx_sdk_vm_impl.py", line 1011, in native_image
return mx.run(native_image_command, nonZeroIsFatal=nonZeroIsFatal, out=out, err=err)
File "/home/ryuta/packages/graal/mx/mx.py", line 12564, in run
abort(retcode)
File "/home/ryuta/packages/graal/mx/mx.py", line 3780, in abort
traceback.print_stack()
Have you verified this issue still happens when using the latest snapshot? The issue happens with the latest snapshot.
Describe the issue
Build failure due to Error: No instances of java.io.FilePermission are allowed in the image heap as this class should be initialized at image runtime.
Code snippet or code repository that reproduces the issue
**PASTE CODE/REPO HERE**
Steps to reproduce the issue Please include both build steps as well as run steps
- clone graal, graalpython, graaljs
- mx --dynamicimports /substratevm,/tools,/sulong,/graalpython,/graal-nodejs build
Expected behavior A clear and concise description of what you expected to happen.
Additional context Add any other context about the problem here. Specially important are stack traces or log output. Feel free to link to gists or to screenshots if necessary
Details
PASTE YOUR LOG/STACK TRACE HERE
FWIW: I'm seeing the exact same problem on Clojure with JDK11 and 20.0.0. Downgrading to 19.3.1 appears to fix it.
FYI: my reproducer for this is latacora/wernicke. I've tried locally with current 20.2.0-dev builds, and the issue has gone away, so I'm hopeful for the next release :)
Same problem, what would be the workaround?
Not sure if you have solved this problem. I have encountered the same issue and here is the root cause and how to fix it.
java.io.FilePermission has been registered as rerun in JDKRegistrations:
https://github.com/oracle/graal/blob/a1226b9e4fc605dfec64696933df375b01010e86/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/jdk/JDKRegistrations.java#L43
This means the FilePermission is always initialized at build time and its InitKind would be RERUN.
But it would not be a problem unless ClassInitializationFeature#checkImageHeapInstance is invoked with FilePermission instance in the parameter. In this case, the check at line 123 in the code below will be true, because FilePermission class is RERUN, it should be initialized at runtime.
https://github.com/oracle/graal/blob/a1226b9e4fc605dfec64696933df375b01010e86/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/classinitialization/ClassInitializationFeature.java#L118-L134
Method checkImageHeapInstance is called when scanning fields that are transitively reached from already initialized classes. For example, given the following code:
import java.io.FilePermission;
import java.util.concurrent.ConcurrentHashMap;
public class Test {
private static ConcurrentHashMap<String, FilePermission> permissions;
static {
permissions = new ConcurrentHashMap<>();
FilePermission fp = new FilePermission(".", "read");
permissions.put("1", fp);
}
public static void main(String[] args) {
FilePermission fp = permissions.get("1");
System.out.println(fp.getActions());
}
}
Run native-image -cp . Test will be OK, but run with native-image -cp . Test --initialize-at-build-time=Test will get the exception:
Fatal error: org.graalvm.compiler.debug.GraalError: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of java.io.FilePermission are allowed in the image heap as this class should be initialized at image runtime. To see how this object got instantiated use --trace-object-instantiation=java.io.FilePermission.
at com.oracle.graal.pointsto.util.AnalysisFuture.setException(AnalysisFuture.java:49)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:269)
at com.oracle.graal.pointsto.util.AnalysisFuture.ensureDone(AnalysisFuture.java:63)
at com.oracle.graal.pointsto.heap.ImageHeapScanner.lambda$postTask$9(ImageHeapScanner.java:611)
at com.oracle.graal.pointsto.util.CompletionExecutor.executeCommand(CompletionExecutor.java:193)
at com.oracle.graal.pointsto.util.CompletionExecutor.lambda$executeService$0(CompletionExecutor.java:177)
at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of java.io.FilePermission are allowed in the image heap as this class should be initialized at image runtime. To see how this object got instantiated use --trace-object-instantiation=java.io.FilePermission.
at com.oracle.svm.hosted.classinitialization.ClassInitializationFeature.checkImageHeapInstance(ClassInitializationFeature.java:135)
at com.oracle.graal.pointsto.meta.AnalysisUniverse.replaceObject(AnalysisUniverse.java:582)
at com.oracle.svm.hosted.ameta.AnalysisConstantReflectionProvider.replaceObject(AnalysisConstantReflectionProvider.java:257)
at com.oracle.svm.hosted.ameta.AnalysisConstantReflectionProvider.interceptValue(AnalysisConstantReflectionProvider.java:228)
at com.oracle.svm.hosted.heap.SVMImageHeapScanner.transformFieldValue(SVMImageHeapScanner.java:126)
at com.oracle.graal.pointsto.heap.ImageHeapScanner.onFieldValueReachable(ImageHeapScanner.java:331)
at com.oracle.graal.pointsto.heap.ImageHeapScanner.lambda$createImageHeapObject$3(ImageHeapScanner.java:272)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
... 10 more
In the first case, Test class is by default initialized at runtime, so the FilePermission object will not be scanned. In the second case, Test class is forced to be initialized at build time, so FilePermission object is scanned and the error is reported.
To solve this problem, you need to find out which class' initialization makes FilePermission object reachable, and then turn it to runtime initialization by --initialize-at-run-time= option.
Generally, --trace-object-instantiation and --trace-class-initialization options would be helpful to find out the root cause of class initialization. Run native-image -cp . Test --initialize-at-build-time=Test --trace-object-instantiation=java.io.FilePermission, you can see:
Fatal error: org.graalvm.compiler.debug.GraalError: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of java.io.FilePermission are allowed in the image heap as this class should be initialized at image runtime. Object has been initialized by the Test class initializer with a trace:
at java.io.FilePermission.<init>(FilePermission.java:487)
at Test.<clinit>(Test.java:10)
The root cause is the initialization of Test class.
But sometimes --trace-object-instantiation and --trace-class-initialization may not work as expected. For example, using --trace-object-instantiation may get Object has been initialized without the native-image initialization instrumentation and the stack trace can't be tracked. In this case, debugging on GraalVM's source would be helpful. My approach is to set a breakpoint at where the UnsupportedFeatureException is thrown, and then recursively check the scan reason. Following pictures show an exaple process.
Now you can see com.alibaba.fastjson.util.ASMClassLoader.DOMAIN is the scan's root reason. And it is scanned because class ASMClassLoader is initialized at build time. So set it to initialize at runtime will solve the problem.
@oroppas, can you please if this issue happens in the latest GraalVM snapshot?
Hi @fernando-valdez, thanks for reminding me. I haven't seen this issue with the recent GraalVM. Closing.