Dear Maintainers,
VisualVM as packaged and using the provided /usr/bin/visualvm to launch it is
currently unusable at least with the JDK 21 (default JDK) and JDK 11, I haven't
tested others. It seems to trigger some JRE bug in the initialization phase:
Error occurred during initialization of VM
java.lang.StackOverflowError
at
java.security.BasicPermission.init(java.base@11.0.25/BasicPermission.java:107)
at
java.security.BasicPermission.<init>(java.base@11.0.25/BasicPermission.java:130)
at
java.lang.RuntimePermission.<init>(java.base@11.0.25/RuntimePermission.java:420)
at
java.lang.System.setSecurityManager0(java.base@11.0.25/System.java:342)
at
java.lang.System.setSecurityManager(java.base@11.0.25/System.java:333)
at allow.uninstall(Unknown Source)
at allow.checkPermission(Unknown Source)
at
java.lang.System.setSecurityManager0(java.base@11.0.25/System.java:342)
at
java.lang.System.setSecurityManager(java.base@11.0.25/System.java:333)
at allow.uninstall(Unknown Source)
at allow.checkPermission(Unknown Source)
at
java.lang.System.setSecurityManager0(java.base@11.0.25/System.java:342)
at
java.lang.System.setSecurityManager(java.base@11.0.25/System.java:333)
# (...) snipped: 252 identical recursions
at allow.uninstall(Unknown Source)
at allow.checkPermission(Unknown Source)
at
java.lang.System.setSecurityManager0(java.base@11.0.25/System.java:342)
As a workaround, removing -Djava.security.manager=allow from the JVM options
make it usable with the JDK 11 but not the default JDK (21):
java.lang.UnsupportedOperationException: The Security Manager is deprecated and
will be removed in a future release
at java.base/java.lang.System.setSecurityManager(System.java:430)
at org.netbeans.TopSecurityManager.install(Unknown Source)
at org.netbeans.core.NbLifecycleManager.advancePolicy(Unknown Source)
at org.netbeans.core.GuiRunLevel.run(Unknown Source)
at org.netbeans.core.startup.Main.start(Unknown Source)
at org.netbeans.core.startup.TopThreadGroup.run(Unknown Source)
at java.base/java.lang.Thread.run(Thread.java:1583)
I haven't investigated further options tweaking to make it work with the JDK
21.
Best regards,
We believe that the bug you reported is fixed in the latest version of
visualvm, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1089580@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Matthias Klose <doko@debian.org> (supplier of updated visualvm package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 23 Jan 2025 07:03:41 +0100
Source: visualvm
Architecture: source
Version: 2.1.10-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Changed-By: Matthias Klose <doko@debian.org>
Closes: 1089580
Changes:
visualvm (2.1.10-1) unstable; urgency=medium
.
[ Matthias Klose ]
* Team upload.
* New upstream version. Closes: #1089580.
* Remove myself as uploader.
.
[ Vladimir Petko ]
* d/rules: disable --release option when building visualvm.
Netbeans platform nb-javac task uses --release option that hides sun.*
classes. VisualVM should be compiled with -source/-target options instead.
Checksums-Sha1:
65703f41c517e6800075b057fb93838cba5ced05 2137 visualvm_2.1.10-1.dsc
7086844d7f25fe104356a573e20d206c417c4ace 11782775 visualvm_2.1.10.orig.tar.gz
077168a25fc91def518ec771918e817c852b6b01 119724 visualvm_2.1.10-1.debian.tar.xz
b952f89c6744d363f52f426fcfe900b2d8f682e1 12736 visualvm_2.1.10-1_source.buildinfo
Checksums-Sha256:
f2879673b484b6556c7d5493d5b710a154d042a0afd48fbddcf00b0b19418c08 2137 visualvm_2.1.10-1.dsc
6ec7df6985d9e4aabfd086b3abb347cdcd1bd4dcc99a8fd9c5ce1e2894922193 11782775 visualvm_2.1.10.orig.tar.gz
f72ae322b5f3d67321aca03ccd92c39d5bb744948798b43e7feb81328f3e8476 119724 visualvm_2.1.10-1.debian.tar.xz
c03a0e5e0b4e17884f28bb43eedd5b94b491c55096ee1fd88cd1d990da9e8ec1 12736 visualvm_2.1.10-1_source.buildinfo
Files:
9819a0c0bb072bbe854b014824c3c58e 2137 java optional visualvm_2.1.10-1.dsc
f100847b73233ec39486b699ecf2c2cb 11782775 java optional visualvm_2.1.10.orig.tar.gz
26b833669264899b67e95d86f1f5c68b 119724 java optional visualvm_2.1.10-1.debian.tar.xz
1a35dcc5ac323fd83f5f9aaab300b453 12736 java optional visualvm_2.1.10-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQJEBAEBCgAuFiEE1WVxuIqLuvFAv2PWvX6qYHePpvUFAmeR3wIQHGRva29AZGVi
aWFuLm9yZwAKCRC9fqpgd4+m9XnwD/9c85m614FE1v7QWV8Z2QY0US+yNkRhvqiw
/wIYj1/zeQfQb780expW3e0uKEAX+sIlHYh/sTubKydFXXJDM1J/BKe3N5ro9sgc
tZrCsiFYk/wPO979DmeBCF6+tbZzB/h3ehYLQ8K3qPM7rabXdy0balFIctImaK7B
3iHKm0uDl6Qp957rwpNy6wv48k46+MQIausZGVHBRZnk0LJJr6XtT2d2v9+cuBes
z/1Xe+FXgny5aAB5LwfUTFPBGn59gOLdS/Ee/qj4sv9GOsORP9YJvUmoQyoSr+JP
PjmWj5wWxAFXQO21eXGUM6RcpqW60bJiEzDoF0sjlmoT+d2D8c/3jxVyG0nxqT9V
8sYp+bI1Sb/7S72mZIsnfJCRIe1D1ZWTFE8eLG/p03luJUX3PmvaQyP6+IcQJnJS
825Ch9d4bLK1t0aswkvqELykJ6rcKmXyJASzZaJrsxyfWaF12+8romuhDrBWBMME
4g9TQEeGQXOLMCJVUH/G4pf33fGN6e0Fh5W6Flp6ubVOPRX/rSm7Wyj+YIh8IZSt
/fc40dJ3+ihJwNvDn2JYoR0rt+Jh4jv9XibIE6TexOP0CT2mt8MxRCzJe4FLCSJI
N112pvYvLWx1fxbhwJ92+LxvvcA0VUdQ89W4B/udjQUxDhpLzuNW4yzZTtYu+0Pj
7eWAB4I/oA==
=DP9Q
-----END PGP SIGNATURE-----
Dear Maintainers, Reopening: unfortunately the same problems are still present in 2.1.10-1. Best regards,
I'm unable to reproduce this. Please provide detailed steps how to reproduce this.
I faced the same problem today and I guess there is a problem with Java 11, or at least with the OpenJDK 11 bundled by Debian unstable. The start script /usr/bin/visualvm has code which always selects Java 11, when installed. When changing line 80 as follows, it starts properly with Java 21. - for j in /usr/lib/jvm/java-11-openjdk-$ARCH /usr/lib/jvm/default-java; do + for j in /usr/lib/jvm/default-java; do Default java points to the following JVM on my machine: java-1.21.0-openjdk-amd64 Hope that helps to reproduce the issue. Best Regards Tobias
Hi, While trying to craft a Vagrantfile to reproduce this it appeared that I misdiagnosed the issue in multiple ways. The packaged visualvm actually runs fine with the default JDK when the JDK 11 is not installed. The issue can be reproduced by installing a JDK 11 on a Trixie system. I'm attaching a Vagrantfile [1] for testing. The `visualvm` startup script ignores JAVA_HOME and uses the JDK 11 if it's installed on the system rather than the default JDK and I didn't notice this before filing this bug report. It is possible to work around this issue either by using the --jdkhome CLI argument, or by adding a configuration file, e.g.: echo visualvm_jdkhome=/usr/lib/jvm/default-java > ~/.visualvm/2.1.10/etc/visualvm.conf Le 2025-02-04 14:26, Tobias Wich a écrit : is still necessary. The modification suggested above should be enough to close this bug. For the record: - removing -Djava.security.manager=allow from the java invocation makes it possible to run visualvm with the JDK 11. On my system it is usable, but on the VM with a 16bpp depth the graphical rendering is unusable (windows only show a uniform plain color), reconfiguring the X server for a 24bpp depth makes visualvm/JDK11 usable again - setting the property above is required to run visualvm with the default JDK 21 (with deprecation warnings though); runs fine with 16bpp and 24bpp depths - there is probably an underlying bug either in the JDK 11 or in visualvm that causes the JVM to crash when the (required for JDK21) property is defined. Thanks, [1]: https://salsa.debian.org/-/snippets/773