I have developers that came to me with an interesting issue in regards to Apache Ignite and Java. This is on a HPUX 11.31 IA platform with Apache-Ignite version 1.3.0-incubating and our HP-UX Java build is 1.7.0.13-jinteg_2015_05_22_03_42-b00. The below error is what has been passed to me but I can't find that Apache-Ignite is supported or tested on HPUX and the BUS_ADRALN error seems to always result in C++ search hits. Anyway if some light could be shed on what our issue is it would be greatly appreciated as I have spent two days trying to find anything on it.
ERROR
"siginfo:si_signo=SIGBUS: si_errno=0, si_code=1 (BUS_ADRALN), si_addr=1fffffffa98e8fe9"
this is thrown after the call to create the readyQueue cache in Ignite. This fatal exception means there is an "invalid address alignment" when trying to memory during the installation of cache.
The developers also sent me a couple logs if that would be of assistance.
A bug in Ignite's Jira for the same issue has been created, the bug has more detailed information about the setup and stack causing the error.
https://issues.apache.org/jira/browse/IGNITE-1493
Chris,
This looks very interesting. When writting a class during marshalling Ignite first writes an internal byte flag, followed by some other data. Therefore offset 17 at the moment of crash mentioned in the ticket makes sense: 16 + 1 (our byte).
I have several assumptions here:
1) We are out of bounds of the array.
2) Byte array element length is not 1.
3) Something else (alignment problem? JMV bug?).
Can you please do the following if possible:
1) Provide GridUnsafeDataOutput.bytes array length at the moment of crash. From the crash report I see that there is some array of length 4096 on the stack. Most probably this is GridUnsafeDataOutput.bytes, but we need to be 100% sure.
2) Run the following program on affected machine and provide the output:
public static void main(String[] args) {
sun.misc.Unsafe unsafe = org.apache.ignite.internal.util.GridUnsafe.unsafe();
System.out.println(unsafe.arrayBaseOffset(byte[].class));
System.out.println(unsafe.arrayIndexScale(byte[].class));
}
This way we will know runtime JVM array parameters.
Related
I used my own xlst transformator in java (XSLTTransformator) but transformation is very big and I have got error:
Caused by: javax.xml.transform.TransformerConfigurationException: JAXP0801002: the compiler encountered an XPath expression containing '107' operators that exceeds the '100' limit set by 'FEATURE_SECURE_PROCESSING'.
at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:990)
at com.aspp.dms.ruleengine.transformation.TemplatesCache.retrieveUncached(TemplatesCache.java:44)
at com.aspp.dms.ruleengine.transformation.TemplatesCache.retrieveUncached(TemplatesCache.java:21)
at com.gratex.java.util.SoftValueCache.get(SoftValueCache.java:41)
at com.aspp.dms.ruleengine.transformation.XSLTTransformator.transform(XSLTTransformator.java:73)
Can you please help me find correct argument for java to solve my problem? Something like -DxpathOperatorsLimit=150
thank you
That behaviour seems to come from new FEATURE_SECURE_PROCESSING, which Oracle introduced in a recent "update" of their Java. See: https://www.oracle.com/java/technologies/javase/11-0-15-relnotes.html
It is 3 parameters they introduced:
jdk.xml.xpathExprGrpLimit Description: Limits the number of groups
an XPath expression can contain. Default 10.
jdk.xml.xpathExprOpLimit Description: Limits the number of operators
an XPath expression can contain. Default 100.
jdk.xml.xpathTotalOpLimit Description: Limits the total number of
XPath operators in an XSL Stylesheet. Default 10000.
Your problem is on #2 (JAXP0801002, default 100).
We got a very similar issue on #3 (JAXP0801003, default 10.000), with this message (quoted, so google will find it):
ERROR: 'JAXP0801003: the compiler encountered XPath expressions with an accumulated '10.002' operators that exceeds the '10.000' limit set by 'FEATURE_SECURE_PROCESSING'.'
FATAL ERROR: 'JAXP0801003: the compiler encountered XPath expressions with an accumulated '10.002' operators that exceeds the '10.000' limit set by 'FEATURE_SECURE_PROCESSING'.'
We wasted 2 days in getting away of that sh*t.
We added some parameters to the java call:
java -Djdk.xml.xpathExprGrpLimit=0 -Djdk.xml.xpathExprOpLimit=0 -Djdk.xml.xpathTotalOpLimit=0 -Xmx2g -Xms512m -XX:-UseGCOverheadLimit ....
Parameters 1,2,3 to to solve the issue. Values "0" set the limits to "off". As XPath can now get huge, it might be advisable to set the heap and stack size and change behaviour of the garbage collection (parameters 4-6).
I hope it will help you too. Have fun!
If you are running into this problem on MacBook M1 or newer. Try a compatible jdk version from either amazon corretto or zulu. I had to try multiple versions for it to work but specifically 8.275.
https://www.azul.com/downloads/?version=java-8-lts&os=macos&architecture=arm-64-bit&package=jdk&show-old-builds=true
Hope this helps!
Rahul Meena
-Djdk.xml.xpathExprGrpLimit=0 -Djdk.xml.xpathExprOpLimit=0 -Djdk.xml.xpathTotalOpLimit=0
Put 3 steps in your restart files.
I encounter this error in my M1 mbp with Oracle OpenJDK17. It also occurs when running in product env that is based on OpenJDK17 and centos.
This answer surely helps me. But I can not modify all JVM configurations in our product cluster.
So I just set these three parameters using Java code:
System.setProperty("jdk.xml.xpathExprGrpLimit", "0");
System.setProperty("jdk.xml.xpathExprOpLimit", "0");
System.setProperty("jdk.xml.xpathTotalOpLimit", "0");
Notice: Set these parameters before TransformerFactory initialization.
I have following code for studying.
My calculate function produces unexpected results when runs on aparapi.
Is there any problem with my code, or aparapi?
Results are;
Result Num Expected
2026982348 406816880 40681688012
2026982516 406816881 40681688180
2026982594 406816882 40681688258
2026982662 406816883 40681688326
2026982830 406816884 40681688494
2026982898 406816885 40681688562
2026982966 406816886 40681688630
2026983044 406816887 40681688708
2026983212 406816888 40681688876
2026983280 406816889 40681688944
2026983338 406816890 40681689002
2026983506 406816891 40681689170
2026983584 406816892 40681689248
2026983652 406816893 40681689316
2026983820 406816894 40681689484
2026983888 406816895 40681689552
2026983956 406816896 40681689620
2026984134 406816897 40681689798
2026984202 406816898 40681689866
2026984270 406816899 40681689934
Edit: If I set executionMode JTP or CPU, I get true results (result == expected) but on GPU mode there is a problem. I'm using late 2013 macbook pro retina with windows 10.
Edit2: Return line of my calculate method causes the problem. If I return Long.MAX_VALUE, it works. But (long) tc * 100 (or ((long) tc) * 100) not giving (eg. 40681688900)
I think you should review your code checking against Aparapi Java Kernel Guidelines, expecially paying attention to Other restrictions and Beware Of Side Effects sections.
Remember to keep your code as simpler as you can.
Looking to your code, in the calculate method you make wide use of the modulus (%) operator. I would suggest you to log each calculation in order to be able to compare what you get in JTP mode and what you get in GPU mode, in order to find out if there are some issues with this operator.
EDIT:
In your calculate method you use int variables to hold values, which may hold numbers till 2^31-1, namely 2147483647 as known as Integer.MAX_VALUE.
If you perform int value=2147483647; value++; you will get as a result -2147483648 as known as Integer.MIN_VALUE.
You can alternatively try your program with lower starting numbers or change your variable declarations to long, which may hold Long.MAX_VALUE, namely 2^63-1.
Both long and int values are supported by Aparapi.
Hi I'm the primary maintainer over at the new Aparapi.com and new github repository. We are much more active over at the new project home and even have about a dozen releases in maven central already. You might want to consider moving over to the new Aparapi.
With that said I am a developer at the new Aparapi and ran this test case and confirmed it is a legitimate Aparapi bug. I will look into what is causing the bug and hopefully can get a bug fix in for you before the next release. The issue has been reported here if you would like to track it. Remember this for the new Aparapi project so the bug fix is not likely to show up in the older Aparapi project.
I'm trying to get CPU and memory usage with SNMP. I have a Java code which takes the oid and runs the "get" command. I can reach the values with MIB-II. However when i import HOST-RESOURCES-MIB in the code i can't get CPU information it returns Null. But some oids work properly in HOST-RESOURCES-MIB.
For example:
hrSystemUpTime(.1.3.6.1.2.1.25.1.1.0) gives me the value 3:51:15.07
hrProcessorLoad(.1.3.6.1.2.1.25.3.3.1.2.0) gives me the value Null
What is the problem?
I've solved the problem. In MIBs the information kept in indexes. Thus, in order to reach a particular information, you need to know which index it's kept.So, i did SNMPWalk on .1.3.6.1.2.1.25.3.3.1.2 for hrProcessorLoad (omit zero) and i got the values. We can also use getNext command to reach the correct index.
I recently started using the findbugs static analysis tool in a java build I was doing. The first report came back with loads of High Priority warnings. Being the obsessive type of person, I was ready to go knock them all out. However, I must be missing something. I get most of the warnings when comparing things. Such as the following code:
public void setSpacesPerLevel(int value)
{
if( value >= 0)
{
spacesPerLevel = value;
}
else
{
spacesPerLevel = 0;
}
}
produces a high priority warning at the if statement that reads.
File: Indenter.java, Line: 60, Type:
BIT_AND_ZZ, Priority: High, Category:
CORRECTNESS Check to see if ((...) &
0) == 0 in
sample.Indenter.setSpacesPerLevel(int)
I am comparing an int to an int, seems like a common thing. I get quite a few of that type of error with similar simple comparisons.
I have alot of other high priority warnings on what appears to be simple code blocks. Am I missing something here? I realize that static analysis can produce false positives, but the errors I am seeing seem too trivial of a case to be a false positive.
This one has me scratching my head as well.
for(int spaces = 0;spaces < spacesPerLevel;spaces++)
{
result = result.concat(" ");
}
Which gives the following findbugs warning:
File: Indenter.java, Line: 160, Type: IL_INFINITE_LOOP, Priority: High, Category: CORRECTNESS
There is an apparent infinite loop in sample.Indenter.indent()
This loop doesn't seem to have a way to terminate (other than by perhaps throwing an exception).
Any ideas?
So basically I have a handful of files and 50-60 high priority warnings similar to the ones above. I am using findbugs 1.3.9 and calling it from the findbugs ant task
UPDATE:
I have this build being executed by a hudson server and had the code being instrumented by Clover for code coverage. When I turned that off, all of my high priority warnings disappeared. That makes sense now. Thanks for the feedback.
UPDATE: I have this build being executed by a hudson server and had the code being instrumented by Clover for code coverage. When I turned that off, all of my high priority warnings disappeared. That makes sense now. Thanks for the feedback.
A side note:
for(int spaces = 0;spaces < spacesPerLevel;spaces++)
{
result = result.concat(" ");
}
If result is a java.lang.String, this may be inefficient, as you do the following steps for each space character:
create a new char[] to hold the result of the concatenation
create a new java.lang.String instance that is wrapped around the character array
If you do this repeatedly, especially when result is already long, this takes a lot of time.
If performance (both time and memory) is important for that method, you should consider using a StringBuilder (not thread-safe) or a StringBuffer (thread-safe).
Are you running Findbugs thru Eclipse plugin, ant or gui? is it possible that the code hasn't recompiled since you ran it (before making changes)?
if setSpacesPerLevel isn't too long, post the output of
javap -v TheClassThatContainssetSpacerPerLevel
As for the second bug, you'd have to show the whole loop before one could say if it was a problem.
I recently ran into an issue with Groovy where I was attempting to deal with a very large string (100k characters). I got an error that said the string could not be more than 65,535 characters. I did some searches to try to find out more info and ran across this link that said the problem was with the JVM - https://issues.apache.org/jira/browse/GROOVY-2382.
I thought Java ran on the JVM as well and in Java I have had much larger strings. Just trying to understand. Can anyone shed some light on this for me. Thank you in advance.
Sean
This is a limitation on string literals, i.e. Strings in the source code.
It is not a problem for Strings read from a File or some other InputStream.
You should move your huge String into a separate text file.
Looking at the source for java.lang.String the limit is that of Integer.MAX_VALUE which is pretty big.
So yes there is a limit but 100K is no where near it.
The limit that the Groovy bug refers to it that of a string literal, this isn't the same as creating a very big string.