Here is a simple Java application:
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
public class Main {
interface MyInterface {
void myMethod();
}
public static void main(String[] args) {
MyInterface myInterface = (MyInterface) Proxy.newProxyInstance(Main.class.getClassLoader(), new Class[] {MyInterface.class},
new InvocationHandler() {
#Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
return method.invoke(proxy, args);
}
});
myInterface.myMethod();
}
}
I would expect to get a simple StackOverflowError here, because I am recursively calling the same method on the proxy instance.
However, the stack trace produced by the exception contains millions of lines and hundreds of MBs in size.
The first part of the stack trace starts like this:
java.lang.reflect.UndeclaredThrowableException
at $Proxy0.myMethod(Unknown Source)
at Main.main(Main.java:22)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at Main$1.invoke(Main.java:18)
... 2 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy0.myMethod(Unknown Source)
... 7 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at Main$1.invoke(Main.java:18)
... 8 more
and extends to:
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy0.myMethod(Unknown Source)
... 1022 more
Then follow millions of lines like:
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at Main$1.invoke(Main.java:18)
at $Proxy0.myMethod(Unknown Source)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at Main$1.invoke(Main.java:18)
.......
and:
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy0.myMethod(Unknown Source)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at Main$1.invoke(Main.java:18)
at $Proxy0.myMethod(Unknown Source)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at Main$1.invoke(Main.java:18)
.......
The last printed line is (after the repeating sequence above):
Exception: java.lang.StackOverflowError thrown from the UncaughtExceptionHandler in thread "main"
I suspected that stack trace generation mechanism was calling some methods on the proxy instance (maybe toString to print it, or something else), thus repeating the recursion over and over again (because each method call on the proxy leads to infinite recursion), but the total count of proxy method executions is 1919 (measured by incrementing a counter in the InvocationHandler.invoke method).
In my real use case I fixed the infinite recursion issue of course; I am just curious if anyone knows if this is some bug or there is a reasonable explanation?
Java version:
java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)
EDIT
#JiriTousek and #AndrewWilliamson kindly provided an analysis of what may be the cause for this. I implemented a simulation based on their input:
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.UndeclaredThrowableException;
public class Test {
private static int counter = 0;
public static void main(String[] args) {
proxy();
}
private static void proxy() {
try {
methodInvoke();
} catch (Throwable e) {
throw new UndeclaredThrowableException(e);
}
}
private static void methodInvoke() throws InvocationTargetException {
try {
myMethod();
} catch (Throwable e) {
throw new InvocationTargetException(e);
}
}
private static void myMethod() {
if (counter++ == 5) {
throw new StackOverflowError();
}
proxy();
}
}
This results in the following stack trace:
Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
at Test.proxy(Test.java:16)
at Test.main(Test.java:9)
Caused by: java.lang.reflect.InvocationTargetException
at Test.methodInvoke(Test.java:24)
at Test.proxy(Test.java:14)
... 1 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at Test.proxy(Test.java:16)
at Test.myMethod(Test.java:32)
at Test.methodInvoke(Test.java:22)
... 2 more
Caused by: java.lang.reflect.InvocationTargetException
at Test.methodInvoke(Test.java:24)
at Test.proxy(Test.java:14)
... 4 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at Test.proxy(Test.java:16)
at Test.myMethod(Test.java:32)
at Test.methodInvoke(Test.java:22)
... 5 more
Caused by: java.lang.reflect.InvocationTargetException
at Test.methodInvoke(Test.java:24)
at Test.proxy(Test.java:14)
... 7 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at Test.proxy(Test.java:16)
at Test.myMethod(Test.java:32)
at Test.methodInvoke(Test.java:22)
... 8 more
Caused by: java.lang.reflect.InvocationTargetException
at Test.methodInvoke(Test.java:24)
at Test.proxy(Test.java:14)
... 10 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at Test.proxy(Test.java:16)
at Test.myMethod(Test.java:32)
at Test.methodInvoke(Test.java:22)
... 11 more
Caused by: java.lang.reflect.InvocationTargetException
at Test.methodInvoke(Test.java:24)
at Test.proxy(Test.java:14)
... 13 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at Test.proxy(Test.java:16)
at Test.myMethod(Test.java:32)
at Test.methodInvoke(Test.java:22)
... 14 more
Caused by: java.lang.reflect.InvocationTargetException
at Test.methodInvoke(Test.java:24)
at Test.proxy(Test.java:14)
... 16 more
Caused by: java.lang.StackOverflowError
at Test.myMethod(Test.java:30)
at Test.methodInvoke(Test.java:22)
... 17 more
So, there is no line numbers growth for each stack frame.
My interpretation of this stack trace is:
When the stack overflow finally happened, a StackOverflowError was thrown
This error was caught by method.invoke() and translated into an InvocationTargetException (as per it's javadoc), with the original exception as a cause
Since this exception is a checked exception, the Proxy could not let it fall through itself, so it caught it and translated it into a UndeclaredThrowableException, again with the previous as a cause
This way, for each level of recursion before stack overflow you got two other "caused by" exceptions along with their stack traces - a lot of output. As for how much output, let's guesstimate it:
about 2000 invocations as per your post
in each invocation, the stack trace seems to grow by 5 lines
2 errors and stack traces printed for each invocation
So the biggest stack trace will have some 10000 lines, average stack trace will have about 5000 lines, everything is printed twice (once for each exception type), that sums up to about 2000 * 5000 * 2 = 20 millions of lines.
The printed stack trace is not truncated when depth of identical traces is longer than 1024 (default value). That's why the last truncated trace ends with ... 1022 more while all of the subsequent ones are printed fully.
The default can be changed by setting MaxJavaStackTraceDepth JVM argument to the desired value. When I increased it for the original example with Proxy by running it with -XX:MaxJavaStackTraceDepth=8192, the entire printed stack trace dropped to about 12500 lines, ending with:
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at Main1$1.invoke(Main1.java:16)
... 7003 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy0.myMethod(Unknown Source)
... 7007 more
Exception: java.lang.StackOverflowError thrown from the UncaughtExceptionHandler in thread "main"
Related
My Code was working with org.owasp.esapi 2.2.0.0 but after upgrading to 2.2.3.1 I am getting ClassNotFoundException.
My Code is something like:
Properties esapiProps = new Properties();
try {
esapiProps.load( SecurityUtil.class.getResourceAsStream("/ESAPI.properties") );
} catch (IOException | NullPointerException e) {
logger.log(Level.SEVERE, "esapi Exception: ", e);
}
ESAPI.override( new DefaultSecurityConfiguration(esapiProps));
// ----- Then canonicalize an input -----
ESAPI.encoder().canonicalize(input);
I read the release notes and added some properties and esapi-java-logging
my ESAPI.properties (in class path)
ESAPI.printProperties=true
LogLevel=INFO
ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder
Encoder.AllowMultipleEncoding=false
Encoder.AllowMixedEncoding=false
Encoder.DefaultCodecList=HTMLEntityCodec,PercentCodec,JavaScriptCodec
ESAPI.Logger=org.owasp.esapi.reference.JavaLogFactory
Logger.ApplicationName=My Test Application
Logger.LogEncodingRequired=false
Logger.LogApplicationName=true
Logger.LogServerIP=true
Logger.LogFileName=ESAPI_logging_file
Logger.MaxLogFileSize=10000000
Logger.UserInfo=true
Logger.ClientInfo=true
my esapi-java-logging.properties (in class path)
handlers= java.util.logging.ConsoleHandler
.level= INFO
java.util.logging.ConsoleHandler.level = INFO
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.SimpleFormatter.format=[%1$tF %1$tT] [%3$-7s] %5$s %n
but I get this exception:
[ERROR ] SRVE0315E: An exception occurred: java.lang.Throwable: org.owasp.esapi.errors.ConfigurationException: java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:5095)
at [internal classes]
Caused by: org.owasp.esapi.errors.ConfigurationException: java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:129)
at org.owasp.esapi.ESAPI.encoder(ESAPI.java:101)
.
.
.
at sun.reflect.GeneratedMethodAccessor521.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.wink.server.internal.handlers.InvokeMethodHandler.handleRequest(InvokeMethodHandler.java:63)
... 1 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor522.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:86)
... 8 more
Caused by: org.owasp.esapi.errors.ConfigurationException: java.lang.ClassNotFoundException: org.owasp.esapi.reference.JavaLogFactory LogFactory class (org.owasp.esapi.reference.JavaLogFactory) must be in class path.
... 17 more
Caused by: java.lang.ClassNotFoundException: org.owasp.esapi.reference.JavaLogFactory
at com.ibm.ws.classloading.internal.AppClassLoader.findClassCommonLibraryClassLoaders(AppClassLoader.java:569)
at [internal classes]
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.owasp.esapi.util.ObjFactory.loadClassByStringName(ObjFactory.java:158)
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:81)
... 15 more
If I change my ESAPI.properties and copy what is in https://raw.githubusercontent.com/ESAPI/esapi-java-legacy/develop/configuration/esapi/ESAPI.properties, ClassNotFoundException goes away and I get NullPointerException exception:
[ERROR ] SRVE0315E: An exception occurred: java.lang.Throwable: org.owasp.esapi.errors.ConfigurationException: java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:5095)
at [internal classes]
Caused by: org.owasp.esapi.errors.ConfigurationException: java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:129)
at org.owasp.esapi.ESAPI.encoder(ESAPI.java:101)
.
.
.
at sun.reflect.GeneratedMethodAccessor522.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.wink.server.internal.handlers.InvokeMethodHandler.handleRequest(InvokeMethodHandler.java:63)
... 1 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor523.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:86)
... 8 more
Caused by: java.lang.ExceptionInInitializerError
... 20 more
Caused by: java.lang.NullPointerException
... 22 more
You said that you read the release notes. The reason for your problem is a detail that you missed that was documented there. Look in those release notes, in the section labeled:
*** IMPORTANT WORKAROUND for 2.2.1.0 ESAPI Logging ***
There, it states:
Lastly, if you try to use the new ESAPI 2.2.1.0 logging, you will notice that you need to change ESAPI.Logger and also possibly provide some other logging properties as well. This is because the logger packages were reorganized to improve maintainability, but we failed to mention it. To use ESAPI logging in ESAPI 2.2.1.0 (and later), you MUST set the ESAPI.Logger property to one of:
org.owasp.esapi.logging.java.JavaLogFactory - To use the new default, java.util.logging (JUL)
org.owasp.esapi.logging.log4j.Log4JLogFactory - To use the end-of-life Log4J 1.x logger
org.owasp.esapi.logging.slf4j.Slf4JLogFactory - To use the new (to release 2.2.0.0) SLF4J logger
Between that and a careful reading of your exception stack trace:
... deleted...
Caused by: org.owasp.esapi.errors.ConfigurationException: java.lang.ClassNotFoundException: org.owasp.esapi.reference.JavaLogFactory LogFactory class (org.owasp.esapi.reference.JavaLogFactory) must be in class path.
... 17 more
Caused by: java.lang.ClassNotFoundException: org.owasp.esapi.reference.JavaLogFactory
...deleted...
I think that should explain the reason. Those classes were reorganized to different packages to accommodate SLF4J logging.
There is some typo with logger factory config in ESAPI.properties. The classes are in org.owasp.esapi.logging.*.
#ESAPI.Logger=org.owasp.esapi.logging.log4j.Log4JLogFactory
#ESAPI.Logger=org.owasp.esapi.logging.slf4j.Slf4JLogFactory
ESAPI.Logger=org.owasp.esapi.logging.java.JavaLogFactory
A couple days ago, I got a support ticket for this NullPointerException:
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract com.redacted.SalesResponsePagination com.redacted.StatisticsService.findSalesData(com.redacted.ConfStats) throws com.redacted.AsyncException' threw an unexpected exception: java.lang.NullPointerException
at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:389)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:579)
at ... (typical GWT + Tomcat stacktrace)
Caused by: java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source)
at java.util.concurrent.ForkJoinTask.reportException(Unknown Source)
at java.util.concurrent.ForkJoinTask.invoke(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.forEach(Unknown Source)
at com.redacted.StatisticsControllerImpl.replacePrices(StatisticsControllerImpl.java:310)
at com.redacted.StatisticsControllerImpl.findSalesData(StatisticsControllerImpl.java:288)
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.GeneratedMethodAccessor752.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:561)
... 33 more
Caused by: java.lang.NullPointerException
at com.redacted.StatisticsControllerImpl.lambda$replacePrices$27(StatisticsControllerImpl.java:317)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(Unknown Source)
at ... (typical stream.forEach stacktrace)
Now, this was an easy one because the exact line number for the NPE was in plain sight; all I had to do was go to StatisticsControllerImpl.java:317:
salesResponsePagination.getSalesResponses().parallelStream()
.peek(sr -> /*...*/)
.filter(sr -> /*...*/)
/*310*/ .forEach(sr -> {
final List<CartElement> sentCEs = DaoService.getCartElementDAO().getSentCEs(/*...*/);
if (sentCEs != null && !sentCEs.isEmpty() && sentCEs.get(0) != null) {
final CartElement ce = sentCEs.get(0);
// some more non-NPE lines...
/*317*/ if (sr.getCurrency().equals(ce.getPurchaseCurrency()) && sr.getPrice().equals(ce.getPurchasePrice().intValue()) && !ce.getCurrency().equals(ce.getPurchaseCurrency())) {
// Some currency exchanging
}
// Etcetera (about 12 lines more)
});
And replace the .equals() calls with Object.equals() to avoid the NPE (investigating the reasons why some sales were registered with a NULL price or currency came later). Test, commit, push, send ticket to QA.
However, the next day QA returned the ticket saying that the NPE persisted, and they included a new, almost similar stack trace:
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract com.redacted.SalesResponsePagination com.redacted.StatisticsService.findSalesData(com.redacted.ConfStats) throws com.redacted.AsyncException' threw an unexpected exception: java.lang.NullPointerException
at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:389)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:579)
at ... (typical GWT + Tomcat stacktrace)
Caused by: java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source)
at java.util.concurrent.ForkJoinTask.reportException(Unknown Source)
at java.util.concurrent.ForkJoinTask.invoke(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.forEach(Unknown Source)
at com.redacted.StatisticsControllerImpl.replacePrices(StatisticsControllerImpl.java:310)
at com.redacted.StatisticsControllerImpl.findSalesData(StatisticsControllerImpl.java:288)
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:561)
... 33 more
Caused by: java.lang.NullPointerException
This stack trace was exactly the same as the previous one, except for two things:
This call was using NativeMethodAccessorImpl instead of GeneratedMethodAccessor752. Compare:
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.GeneratedMethodAccessor752.invoke(Unknown Source)
vs
at com.redacted.StatisticsServiceImpl.findSalesData(StatisticsServiceImpl.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
This one was missing the stack trace for the lambda. The line where the NPE happened was missing.
This threw me off initially. Why was the last part of the stack trace missing? I asked QA to re-test and re-attach the stack trace a couple times, until I got a complete one; however, the complete one I got in the end was based on GeneratedMethodAccesor once again.
Now, if I understand correctly, sun.reflect.NativeMethodAccessorImpl is used for the first invocations of a method, until JIT has enough info to generate an optimized accesor for that method in the form of sun.reflect.GeneratedMethodAccessorNNN.
What I don't understand is: if Native is using my code and Generated is using JIT's generated code, shouldn't Native show more info about my code, not less?
So my question is:
Why do lambda runtime exceptions thrown inside sun.reflect.NativeMethodAccessorImpl seem to be missing the lambda's stack trace?
Can this be a bug in JDK's source code? Especially when the very same exception thrown inside sun.reflect.GeneratedMethodAccessor includes the lambda stack trace without problem.
The following code manages to get a stack trace similar to the first one. I can force the use of NativeMethodAccessor or GeneratedMethodAccesor by running it with a sufficiently low or high first parameter, respectively (i.e. java test.Main 1 or java test.Main 30).
However, the lambda part of it is always present, whether using Native or Generated.
package test;
import java.lang.reflect.Method;
import java.util.stream.IntStream;
class MyOtherClass {
public void methodWithLambda(boolean fail) {
IntStream.range(0, 1000).parallel().forEach(k -> {
if (fail && k % 500 == 0)
throw new NullPointerException();
});
}
public String methodProxy(boolean fail) {
methodWithLambda(fail);
return "OK";
}
}
class MyClass {
public String methodReflected(Boolean fail) {
return new MyOtherClass().methodProxy(fail);
}
}
class Main {
public static void main(String[] args) throws Exception {
Class<MyClass> clazz = MyClass.class;
Object instance = clazz.newInstance();
Method method = clazz.getMethod("methodReflected", Boolean.class);
int reps = args.length >= 1 ? Integer.valueOf(args[0]) : 20;
for (; reps --> 0;) {
// Several non-failing calls to force creation of GeneratedMethodAccesor
System.out.println((String) method.invoke(instance, false));
}
// Failing call
System.out.println((String) method.invoke(instance, true));
}
}
Stack trace for the above code when using NativeMethodAccesor:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at test.Main.main(Main.java:36)
Caused by: java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.util.concurrent.ForkJoinTask.getThrowableException(Unknown Source)
at java.util.concurrent.ForkJoinTask.reportException(Unknown Source)
at java.util.concurrent.ForkJoinTask.invoke(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfInt.evaluateParallel(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.IntPipeline.forEach(Unknown Source)
at java.util.stream.IntPipeline$Head.forEach(Unknown Source)
at test.MyOtherClass.methodWithLambda(Main.java:8)
at test.MyOtherClass.methodProxy(Main.java:14)
at test.MyClass.methodReflected(Main.java:21)
... 5 more
Caused by: java.lang.NullPointerException
at test.MyOtherClass.lambda$methodWithLambda$0(Main.java:10)
at java.util.stream.ForEachOps$ForEachOp$OfInt.accept(Unknown Source)
at java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Unknown Source)
at java.util.Spliterator$OfInt.forEachRemaining(Unknown Source)
at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
at java.util.stream.ForEachOps$ForEachTask.compute(Unknown Source)
at java.util.concurrent.CountedCompleter.exec(Unknown Source)
at java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.util.concurrent.ForkJoinPool$WorkQueue.execLocalTasks(Unknown Source)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source)
at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
EDIT: Just to be clear: I am not looking for ways to fix this NPE, nor ways to force the lambda's stack trace to print. What I want to know is the reason why the above happens: different implementations? A bug? Something to do with forEach()?
This might be an issue of JDK-6678999, “Stacktrace missing after null string comparisons”:
After comparing a string to null and catching the exception and repeating the operation, JVM starts throwing "stackless" NullPointerException (it occurs after 9000 loops but this is variable)
The evaluation of the issue is
When the server compiler compiles a method, the stack trace in an exception thrown
by that method may be omitted for performance purposes.
[…] If the user always wants stack traces, use the -XX:-OmitStackTraceInFastThrow option to the VM.
So, the option -XX:-OmitStackTraceInFastThrow may solve the issue.
Note that the bug report was against Java 6, but since it has been closed as “Won't Fix”, it may still be relevant, though you would have to replace “server compiler” with “c2 compiler” in the explanation now.
The use of NativeMethodAccessorImpl or GeneratedMethodAccessor… is not relevant to this issue, except that both have a common cause; a higher number of executions may trigger the optimizations.
I am creating about 150 files of around 5MB sizes. Vertx file APIs gives an exception randomly after creating 10-15 files "failed to create a child event loop".
(I am using vertx3 and java8)
Below is my code snippet (After I get a callback then only I call the function again to create the next file. So, file creation is never concurrent):
Vertx.vertx().fileSystem().writeFile(filepath,
Buffer.buffer(dataList.toString()), result -> {
if (result.succeeded()) {
System.out.println("File written");
} else {
System.err.println("Oh oh ..." + result.cause());
}
lambda.callback();
});
Below is my exception stack trace:
java.lang.IllegalStateException: failed to create a child event loop
at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:68)
at io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:49)
at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:61)
at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:52)
at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:132)
at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:126)
at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:122)
at io.vertx.core.impl.VertxFactoryImpl.vertx(VertxFactoryImpl.java:34)
at io.vertx.core.Vertx.vertx(Vertx.java:78)
at rc_datawarehouse.CsvToJsonChunkWriter.writeCsvChunkToFiles(CsvToJsonChunkWriter.java:73)
at rc_datawarehouse.CsvToJsonReadWrite.lambda$2(CsvToJsonReadWrite.java:119)
at rc_datawarehouse.CsvToJsonReadWrite$$Lambda$16/1470881859.handle(Unknown Source)
at io.vertx.core.file.impl.AsyncFileImpl.handleData(AsyncFileImpl.java:335)
at io.vertx.core.file.impl.AsyncFileImpl.lambda$doRead$285(AsyncFileImpl.java:320)
at io.vertx.core.file.impl.AsyncFileImpl$$Lambda$17/1067800899.handle(Unknown Source)
at io.vertx.core.file.impl.AsyncFileImpl$2.lambda$done$289(AsyncFileImpl.java:408)
at io.vertx.core.file.impl.AsyncFileImpl$2$$Lambda$18/1632681662.handle(Unknown Source)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$15(ContextImpl.java:314)
at io.vertx.core.impl.ContextImpl$$Lambda$5/1780132728.run(Unknown Source)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:357)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
at java.lang.Thread.run(Unknown Source)
Caused by: io.netty.channel.ChannelException: failed to open a new selector
at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:128)
at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:120)
at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:87)
at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:64)
... 22 more
Caused by: java.io.IOException: Unable to establish loopback connection
at sun.nio.ch.PipeImpl$Initializer.run(Unknown Source)
at sun.nio.ch.PipeImpl$Initializer.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.nio.ch.PipeImpl.<init>(Unknown Source)
at sun.nio.ch.SelectorProviderImpl.openPipe(Unknown Source)
at java.nio.channels.Pipe.open(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl.<init>(Unknown Source)
at sun.nio.ch.WindowsSelectorProvider.openSelector(Unknown Source)
at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:126)
... 25 more
Caused by: java.net.SocketException: No buffer space available (maximum connections reached?): connect
at sun.nio.ch.Net.connect0(Native Method)
at sun.nio.ch.Net.connect(Unknown Source)
at sun.nio.ch.Net.connect(Unknown Source)
at sun.nio.ch.SocketChannelImpl.connect(Unknown Source)
at java.nio.channels.SocketChannel.open(Unknown Source)
at sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(Unknown Source)
... 34 more
I got my answer from the forum here (Thanks Jez)
Vertx.vertx() is the culprit. It creates a new vertx every time leading to multiple eventloops which seems to be the problem.
I cached it in a variable, rather than using Vertx.vertx() every time and it worked
cachedVertx.fileSystem().writeFile(...)
Im trying to run code use protege-owl. So I added the protege.jar and protege-owl.jar to library to import edu.stanford.smi.protegex.owl.* and edu.stanford.smi.protege.*.
I also added jena jar files to use in next steps.
First i wrote simple code to see how it works :
import java.lang.Object;
import edu.stanford.smi.protege.*;
import edu.stanford.smi.protegex.owl.*;
import edu.stanford.smi.protegex.owl.jena.JenaOWLModel;
import edu.stanford.smi.protegex.owl.model.OWLNamedClass;
public class Main {
public static void main(String[] args) {
// TODO code application logic here
JenaOWLModel model=ProtegeOWL.createJenaOWLModel();
OWLNamedClass c= model.createOWLNamedClass("A");
System.out.print(c.getName());
}
}
But it gives me this error :
CONFIG: Protege 3.0 Build 141, JVM 1.6.0_20-b02, memory=259M, Windows 7, encoding=UTF-8, language=fa, country=IR
WARNING: Look and feel not found: com.jgoodies.plaf.plastic.PlasticLookAndFeel -- SystemUtilities.loadLookAndFeel()
WARNING: Plugins directory not found: C:\Users\mona\Documents\NetBeansProjects\JavaApplication3\plugins -- PluginUtilities.getPluginsDir()
WARNING: Exception Caught -- java.lang.NoClassDefFoundError: com/toedter/calendar/JDateChooser
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at edu.stanford.smi.protege.plugin.PluginUtilities.isLoadableClass(Unknown Source)
at edu.stanford.smi.protege.plugin.PluginUtilities.checkPlugin(Unknown Source)
at edu.stanford.smi.protege.plugin.PluginUtilities.checkPlugins(Unknown Source)
at edu.stanford.smi.protege.plugin.PluginUtilities.processManifest(Unknown Source)
at edu.stanford.smi.protege.plugin.PluginUtilities.loadPluginsWithClassLoader(Unknown Source)
at edu.stanford.smi.protege.plugin.PluginUtilities.createClassLoaderAndLoadPlugins(Unknown Source)
at edu.stanford.smi.protege.plugin.PluginUtilities.loadPlugins(Unknown Source)
at edu.stanford.smi.protege.plugin.PluginUtilities.loadSystemPlugins(Unknown Source)
at edu.stanford.smi.protege.plugin.PluginUtilities.loadPlugins(Unknown Source)
at edu.stanford.smi.protege.plugin.PluginUtilities.init(Unknown Source)
at edu.stanford.smi.protege.plugin.PluginUtilities.<clinit>(Unknown Source)
at edu.stanford.smi.protege.util.SystemUtilities.init(Unknown Source)
at edu.stanford.smi.protege.util.SystemUtilities.<clinit>(Unknown Source)
at edu.stanford.smi.protege.model.Project.<clinit>(Unknown Source)
at edu.stanford.smi.protegex.owl.ProtegeOWL.createJenaOWLModel(ProtegeOWL.java:32)
at javaapplication3.Main.main(Main.java:25)
Caused by: java.lang.ClassNotFoundException: com.toedter.calendar.JDateChooser
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method) . . . .
What can I do ?
Update:
I replace protege.jar with protege-3.5.jar and now it gives :
Exception in thread "main" java.lang.NoSuchMethodError: edu.stanford.smi.protege.model.SystemFrames.replaceFrame(Ledu/stanford/smi/protege/model/Frame;)V
at edu.stanford.smi.protegex.owl.model.impl.AbstractOWLModel.createSystemFrames(AbstractOWLModel.java:544)
at edu.stanford.smi.protege.model.DefaultKnowledgeBase.<init>(DefaultKnowledgeBase.java:79)
at edu.stanford.smi.protegex.owl.model.impl.AbstractOWLModel.<init>(AbstractOWLModel.java:318)
at edu.stanford.smi.protegex.owl.jena.JenaOWLModel.<init>(JenaOWLModel.java:62)
at edu.stanford.smi.protegex.owl.jena.JenaKnowledgeBaseFactory.createKnowledgeBase(JenaKnowledgeBaseFactory.java:55)
at edu.stanford.smi.protege.model.Project.createDomainKB(Project.java:429)
at edu.stanford.smi.protege.model.Project.createDomainKnowledgeBase(Project.java:447)
at edu.stanford.smi.protege.model.Project.<init>(Project.java:359)
at edu.stanford.smi.protege.model.Project.<init>(Project.java:341)
at edu.stanford.smi.protege.model.Project.createNewProject(Project.java:545)
at edu.stanford.smi.protegex.owl.ProtegeOWL.createJenaOWLModel(ProtegeOWL.java:32)
at javaapplication3.Main.main(Main.java:24)
Java Result: 1
Where is the problem?
I downloaded protege-owl.jar which is 3.24MB from different link and now it works.
I have an applet that references 2 signed jars:
myapplet.jar
jackson-all-1.9.9.jar
When starting the applet the second time (first time is without errors), I get this:
Exception in thread "thread applet-main.MyApplet-1"
java.lang.ExceptionInInitializerError
at org.codehaus.jackson.map.deser.StdDeserializerProvider.<init>(StdDeserializerProvider.java:81)
at org.codehaus.jackson.map.ObjectMapper.<init>(ObjectMapper.java:398)
at org.codehaus.jackson.map.ObjectMapper.<init>(ObjectMapper.java:358)
at org.codehaus.jackson.map.ObjectMapper.<init>(ObjectMapper.java:328)
at net.Remote.<init>(Remote.java:50)
at main.Env.init(Env.java:44)
at main.MyApplet.init(MyApplet.java:25)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.SecurityException: Prohibited package name: java.util
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.codehaus.jackson.map.deser.BasicDeserializerFactory.<clinit>(BasicDeserializerFactory.java:74)
... 9 more
The line in question is the first one in the following try-catch block:
try {
Class<?> key = Class.forName("java.util.ConcurrentNavigableMap");
Class<?> value = Class.forName("java.util.ConcurrentSkipListMap");
#SuppressWarnings("unchecked")
Class<? extends Map<?,?>> mapValue = (Class<? extends Map<?,?>>) value;
_mapFallbacks.put(key.getName(), mapValue);
} catch (ClassNotFoundException cnfe) { // occurs on 1.5
}
A couple of things I do not understand:
Why does my Java7 JVM not take it out of its runtime library? But rather
Why does it try to download /java/util/ConcurrentNavigableMap.class from my server, which obviously fails with a 404?
As that fails, why does it try to re-download myapplet.jar 25 times in rapid succession, each time successfully (200), and each time returning the same jar file?
Update I'm not sure whether the 25 retries are caused by the class loader trying to load the class, it might be some other code trying to load a resource (which would still be odd, but not related to the CurrentNavigableMap issue), so I'll exclude that from my question.
N.B. I guess it does not try to re-download the jackson jar file, as that one is listed in the cache_archive attribute.
Is this?
wrong:
Class.forName("java.util.ConcurrentNavigableMap");
Correct:
http://java.sun.com/javase/ja/6/docs/ja/api/java/util/concurrent/package-tree.html
Class.forName("java.util.concurrent.ConcurrentNavigableMap");