Unable to launch Java Virtual Machine on Java 11 [duplicate] - garbage-collection

% java11 -Xlog:gc*:file=c:\max.txt -version
[0.002s][error][logging] Invalid decorator '\max.txt'.
Invalid -Xlog option '-Xlog:gc*:file=c:\max.txt', see error log for
details.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Apparently with Java 9 (and later) unified logging a colon is used as a separator between fields in the -Xlog arguments. So, how do I specify a Windows pathname that has a colon in it? Is there an escape of some kind? If I specify the filename as is, I get the error I included above. Thank you.

One of the ways suggested for solving that on the mailing list is using shell escapes like:
java -Xlog:gc*:file=\"C:\max.txt\" -version
Note that according to Dave Holmes' posting, only double quotes are supported. Depending on the shell, the escaping is necessary so that the Java command sees the quotes.

Related

XSCT executes command in interactive shell but not within script

First, take note that I am using the Xilinx SDK 2018.2 on Kubuntu 22.04 because of my companies policy. I know from research, that the command I'm using is deprecated in newer versions, but in the version I am using, it works flawlessly - kind of... But read for yourself:
My task is to automate all steps in the FPGA build to create a pipeline which automatically builds and tests the FPGAs. To achieve this, I need to build the code - this works flawlessly in XSDK. For automation, this also has to work in the command line, so what I did is following the manual to find out how this is achieved. Everything works as expected if I write it in the interactive prompt like shown here:
user#ubuntuvm:~$ xsct
****** Xilinx Software Commandline Tool (XSCT) v2018.2
**** Build date : Jun 14 2018-20:18:43
** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
xsct%
Then I can enter the commands I need to import all needed files and projects (hw, bsp, main project). With this toolset, everything works as expected.
Because I want to automate it via a pipeline, I decided to pack this into a script for easier access. The script contains exactly the commands I entered in the interactive shell and therefore looks like this:
user#ubuntuvm:~/gitrepos/repository$ cat ../autoBuildScript.tcl
setws /home/user/gitrepos/repository
openhw ./hps_packages/system.hdf
openbsp ./bsp_packages/system.mss
importprojects ./sources/mainApp
importprojects ./bsp_packages
importprojects ./hps_packages
regenbsp -bsp ./bsp_packages/system.mss
projects –clean
projects -build
The commands are identical to the ones entered via the interactive CLI tool, the only difference is that this is now packed into a script. The difference is, that this now does not build completely anymore. I get the following error:
user#ubuntuvm:~/gitrepos/repository$ xsct ../autoBuildScript.tcl
INFO: [Hsi 55-1698] elapsed time for repository loading 1 seconds
Starting xsdk. This could take few seconds... done
'mainApp' will not be imported... [ALREADY EXIST]
'bsp_packages' will not be imported... [ALREADY EXIST]
'hps_packages' will not be imported... [ALREADY EXIST]
/opt/Xilinx/SDK/2018.2/gnu/microblaze/lin
unexpected arguments: –clean
while executing
"error "unexpected arguments: $arglist""
(procedure "::xsdb::get_options" line 69)
invoked from within
"::xsdb::get_options args $options"
(procedure "projects" line 12)
invoked from within
"projects –clean"
(file "../autoBuildScript.tcl" line 8)
I've inserted projects -clean only, because I got the error before with projects -build and wanted to check, if this also happens with another argument.
In the internet I didn't really find anything according to my specific problem. Also I strictly held on to the official manual, in which the command is also used just as I use it - but with the result of it being working.
Also, I've checked the line endings (set to UNIX) because I suspected xsct to read maybe a newline character or something similar, with no result. This error also occurs, when I create the bsp and hardware from sketch. Also, to me the error looks like an internal one from Xilinx, but let me know what you think.
So, it appears that I just fixed the problem on my own. Thanks on everyone reading for being my rubber ducky.
Apparently, the version 2018.2 of XSDK has a few bugs, including inconsistency with their command interpretation. For some reason the command works in the interactive shell, but not in the script - because the command is in its short form. I just learned from a Xilinx tutorial, that projects -build is - even though it works - apparently not the full command. You usually need to clarify, that this command should come from the SDK like this: sdk projects -build. The interactive shell seems to ignore this fact for a reason - and so does the script for any command except projects. Therefore, I added the "sdk" prefix to all commands which I used from the SDK, just to be safe.
I cannot believe, that I just debugged 2 days for an error whose fix only contains 3 (+1 whitespace) letters.
Thanks everybody for reading and have a nice day

Could not resolve placeholder my_propertySource in string value file:$ - error only happens in Unix

I am getting this error only when running in Unix. I mean, with same code, I can run perfectly in Windows.
Exception in thread "main" java.lang.IllegalArgumentException: Could not resolve placeholder 'CONF_DIR' in string value "file:${CONF_DIR}"
at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:174)
…
PropertySource with file:$
#Configuration
#ComponentScan("com…
#EnableBatchProcessing
#PropertySource("file:${CONF_DIR}")
public class BatchConfig {
…
From Windows Command Prompt, it does work perfectly:
C:\20160601>SET CONF_DIR=C:/20160601/config.properties
C:\20160601>java –cp my_executable_jar.jar com/my_company/main
... no error at all since propertySource("file:$... finds the value previously settup
From UNIX z/OS390 shell, the above error happens
===> CONF_DIR=/usr/certain_path/config.properties
===> echo $CONF_DIR
/usr/certain_path/config.properties
===> ./java –cp my_executable_jar.jar com/my_company/main
... now, propertySource("file:$ will not find the value previously settup although I checked and it is there (see the echo)
If I tried straigh inside the BatchConfig class with
#PropertySource("file:/usr/certain_path/config.properties")
it does work. So I am guessing there is some error or misunderstood from myself between java command "file:$" and how I am setting the variable in Unix.
I carefully read a lot about both approaches and, as far as I can see, both are correct. I mean either the way I am setting the shell variable and how I am accessing this. Additionally, it works in Windows.
export CONF_DIR=/usr/certain_path/config.properties
If you don't use the export, it's only set in the current environment. If you export it, then it becomes an environment variable and is inherited by sub-processes.

Ezjail and /etc/jail.conf in FreeBSD 10.2

I have a question regarding the following warning when using
Ezjail-3.4.1 on FreeBSD 10.2
/etc/rc.d/jail: WARNING: Per-jail configuration via jail_* var "enter code here" iables is obsolete. Please consider to migrate to /etc/jail.conf "enter code here"It is my understanding that this has changed in FreeBSD 9.0 but since 10.2 the new way is the default method and that warning is being generated.I haven't been able to find any information about this on google, a lot of users mentioning the errors but ignoring them because their jails still work.AFAIK in 10.0 the rc.d/jail script converts the old-style jail_
variables into a temporary jail.conf to handle the jail. So the warning
is generated by rc.d/jail
Regards
Mr-Hill
As you found out, jails on FreeBSD 10.x use a new configuration method. From /usr/src/UPDATING:
20131010:
The rc.d/jail script has been updated to support jail(8)
configuration file. The "jail_<jname>_*" rc.conf(5) variables
for per-jail configuration are automatically converted to
/var/run/jail.<jname>.conf before the jail(8) utility is invoked.
This is transparently backward compatible. See below about some
incompatibilities and rc.conf(5) manual page for more details.
These variables are now deprecated in favor of jail(8) configuration
file. One can use "rc.d/jail config <jname>" command to generate
a jail(8) configuration file in /var/run/jail.<jname>.conf without
running the jail(8) utility. The default pathname of the
configuration file is /etc/jail.conf and can be specified by
using $jail_conf or $jail_<jname>_conf variables.
Please note that jail_devfs_ruleset accepts an integer at
this moment. Please consider to rewrite the ruleset name
with an integer.
ezjail was never updated to use this new method, but that's ok: FreeBSD still accepts the previous method. You can ignore this warning.

Websphere fails on using reserved words in EL

I've got a JSF1.2 application which deploys fine on Tomcat6 and Tomcat7.
So far so good.
One of the pages contains the following property on a h:inputText:
disabled="#{quoteFinance.quoteSaved or quoteRequest.quoteDisabled or setting.protected}"
This validates and works fine on aforementioned Tomcat servers.
However, websphere8 believes this is a problem and throws the following error:
disabled="#{quoteFinance.quoteSaved or quoteRequest.quoteDisabled or setting.protected}" [protected] is not a valid Java identifier
at com.sun.facelets.tag.TagAttribute.getValueExpression(TagAttribute.java:259)
at com.sun.facelets.tag.jsf.ComponentRule$ValueExpressionMetadata.applyMetadata(ComponentRule.java:69)
at com.sun.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:36)
at com.sun.facelets.tag.MetaTagHandler.setAttributes(MetaTagHandler.java:76)
Cause:
javax.el.ELException: [protected] is not a valid Java identifier
at org.apache.el.parser.AstDotSuffix.setImage(AstDotSuffix.java:45)
at org.apache.el.parser.ELParser.DotSuffix(ELParser.java:1067)
at org.apache.el.parser.ELParser.ValueSuffix(ELParser.java:1033)
at org.apache.el.parser.ELParser.Value(ELParser.java:978)
at org.apache.el.parser.ELParser.Unary(ELParser.java:948)
at org.apache.el.parser.ELParser.Multiplication(ELParser.java:712)
at org.apache.el.parser.ELParser.Math(ELParser.java:632)
at org.apache.el.parser.ELParser.Compare(ELParser.java:444)
at org.apache.el.parser.ELParser.Equality(ELParser.java:338)
at org.apache.el.parser.ELParser.And(ELParser.java:282)
I had a similar issue with #{msg.continue} which is perfectly fine, but because continue is a reserved word, WAS8 throws me an error.
Why does websphere not accept this while the code is working perfectly?
How can I resolve this problem?
Many thanks!
This behaviour is as per EL specification. You need to rename the property name to something which isn't a Java literal, or you need to use the brace notation so that it can be referenced as String.
#{setting['protected']}
and
#{msg['continue']}
This should have failed in Tomcat 7 as well, perhaps you were using a rather old version of Tomcat 7. This was been "fixed" somewhere between 7.0.0 and 7.0.10. It's currently already at 7.0.28.
From the Expression Language 2.2 spec:
An identifier is constrained to be a Java identifier - e.g., no -, no /, etc.
protected can't be used as an identifier in Java as it is reserved.
This restriction applied in EL 2.1 too, so it was likely a bug in your old platform's EL parser that this ever worked.
"protected" is a java reserved word too! just like "continue"

Issues running FSL command in Linux environment

I am new to FSL, using version 4.1.8. I am trying to run a script that reads and generates *.nii files, which format is normally supported by FSL. I am calling an FSL function, probtrackx from within Matlab. However, I get the following error message seemingly unable to generate or recognize *.nii files:
** ERROR (nifti_image_read): failed to find header file for '~/Documents/fMRI_data/../DTI/fsl_dti/masks/target_mask_001'
** ERROR: nifti_image_open(~/Documents/fMRI_data/../DTI/fsl_dti/masks/target_mask_001): bad header info
ERROR: failed to open file ~/Documents/fMRI_data/../DTI/fsl_dti/masks/target_mask_001
ERROR: Could not open image ~/Documents/fMRI_data/../DTI/fsl_dti/masks/target_mask_001
The files do exist but FSL fails to recognize them. Any help as to how to correct the issue and get FSL to work properly would be most appreciated. I suspect it's a Linux settings issue, just not sure how to fix it. A solution to a related problem in a previous posting suggested adding ls='ls --color=auto'. I've tried it to on avail.
Some FSL tools assume that the $FSLDIR unix unvironment variable is set, which might not be the case in your MATLAB environment. You can fix that with something like setenv('FSLDIR', '/usr/local/fsl') (modified of course if your FSL installation is in a different place). Some also need the regular FSL setup script to be executed as well: system('. ${FSLDIR}/etc/fslconf/fsl.sh'). See also: http://www.fmrib.ox.ac.uk/fsl/fsl/downloading.html.
Instead of the more complicated probtrackx script, another thing to try first is simply:
system('fslhd ~/Documents/fMRI_data/../DTI/fsl_dti/masks/target_mask_001')
If this fails with the same error, then you know that you entered the path to the data incorrectly. For example, do you mean to have the .. in there?
Also, in the future, the best place to get FSL support is on their mailing list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=fsl
Does MATLAB have access to run other fsl commands? If you are able to run a command from the command line but not through MATLAB, the MATLAB user may not have access to run fsl or may be looking for some FSL variables.
You might have to do the equivalent of this for a linux system

Resources