I have a bug from my customer and when I look into the log we trace the exception, some of the stacktrace do not have line number:
at xxxx.xxx.xx.x.xx.DayIntervalRule.getInterval(DayIntervalRule.java)
at xxxx.xxx.xx.x.xx.XXSchedule.getNextDueDate(XXSchedule.java)
at xxxx.xxx.xx.x.xx.XXSchedule.evaluateRules(XXSchedule.java)
Please note that:
I have replace the package name into something like"xx"),and all of the class and method are defined in our application:
The full stack trace are as below:
java.lang.NullPointerException
at xxxx.xxx.xx.x.xx.DayIntervalRule.getInterval(DayIntervalRule.java)
at xxxx.xxx.xx.x.xx.XXSchedule.getNextDueDate(XXSchedule.java)
at xxxx.xxx.xx.x.xx.XXSchedule.evaluateRules(XXSchedule.java)
at xxxx.xxx.xx.x.xx.EvaluateRulesVistor.visitXXNode(EvaluateRulesVistor.java:56)
at xxxx.xxx.xx.x.xx.XXNode.accept(XXNode.java:396)
at xxxx.xxx.xx.x.xx.AssetXX.traverseForest(AssetXX.java:351)
at xxxx.xxx.xx.x.xx.AssetXX.run(AssetXX.java:70)
at xxxx.xxx.xx.x.xx.XXEngine.doForecast(XXEngine.java:437)
at xxxx.xxx.xx.x.xx.XXEngine.forecastWorkOrders2(XXEngine.java:380)
I am interested in why this happens?Is it possible that my customer do something to the existing code(customization)?
The code that does not display line numbers was compiled without debug information.
Related
When generating the Javadoc, it adds on prefix to the imported class name, as shown below on the first line 'java.lang'.
How to properly disable that?
Have tried adding -noqualifier in Other command line arguments in my IntelliJ popup window but the following error occurred:
javadoc: error - Illegal package name: "/Users"
Below is a snippet from the Javadoc I generated:
public TrainRoute(java.lang.String name,
int routeNumber)
Creates a new TrainRoute with the given name and number.
Should meet the specification of Route.Route(String, int)
Parameters:
name - The name of the route.
routeNumber - The route number of the route.
I know this is an old question, but still relevant. I am aware of two solution which can be used alone or in combination:
To suppress prefixes on java packages use:
-noqualifier java.*
To suppress prefixes and link to the actual Java docs use:
-link https://docs.oracle.com/javase/8/docs/api
Both suppress the java name qualifiers. The second also links to the Oracle docs.
See javadoc options docs for more info.
Our app is minified and the deobfuscated mappings is uploaded to Play developer console so I am expecting the real line numbers translated when there is a crash. However, the latest stacktrace shows lots of which is making it really hard to troubleshoot. Additionally there is no line number at all. Any idea how this can be improved?
An example stacktrace is like this. I have replaced real class and method names as myclass1 and mymethod0 to mymethod8. Not sure where are these access$xxx methods coming from.
Caused by: java.lang.NullPointerException
at myclass1.mymethod0(myclass1.java)
at <OR>.mymethod1(myclass1.java)
at <OR>.mymethod2(myclass1.java)
at <OR>.mymethod3(myclass1.java)
at <OR>.mymethod4(myclass1.java)
at <OR>.mymethod5(myclass1.java)
at <OR>.mymethod6(myclass1.java)
at <OR>.access$100(myclass1.java)
at <OR>.access$500(myclass1.java)
at <OR>.access$600(myclass1.java)
at myclass1.mymethod7(myclass1.java)
at myclass1.mymethod0(myclass1.java)
at <OR>.mymethod1(myclass1.java)
at <OR>.mymethod2(myclass1.java)
at <OR>.mymethod3(myclass1.java)
at <OR>.mymethod4(myclass1.java)
at <OR>.mymethod5(myclass1.java)
at <OR>.mymethod6(myclass1.java)
at <OR>.access$100(myclass1.java)
at <OR>.access$500(myclass1.java)
at <OR>.access$600(myclass1.java)
at myclass1.mymethod0(myclass1.java)
at <OR>.mymethod1(myclass1.java)
at <OR>.mymethod2(myclass1.java)
at <OR>.mymethod3(myclass1.java)
at <OR>.mymethod4(myclass1.java)
at <OR>.mymethod5(myclass1.java)
at <OR>.mymethod6(myclass1.java)
at <OR>.access$100(myclass1.java)
at <OR>.access$500(myclass1.java)
at <OR>.access$600(myclass1.java)
at myclass1$6.mymethod9(myclass1.java)
When my program prints stack trace in NetBeans IDE, for example this:
Exception in thread "main" java.lang.RuntimeException: Not implemented yet
at App.App.main(App.java:202)
The "App.java:202" part is a link. When I click it, it directs me to the file and line.
I would like to do this in my own logs. Just printing it doesn't work for me.
My not functional log line example:
2015/06/01 10:27:19.197 (DbConnection.java:119) ExecuteQuery ....
Solution:
StackTraceElement s = Thread.currentThread().getStackTrace()[1];
System.out.printf("%s.%s(%s:%s)%n", s.getClassName(), s.getMethodName(),s.getFileName(), s.getLineNumber());
New problem:
If I print this:
App.App.RunTests(App.java:128) th_id:1,main WARN null Database.DbValuesCache.run(DbValuesCache.java:153) ....
.. only the first link works.
What now?
How to print the exact line no of exception in Velocity Template at runtime?
I am using Veloeclipse for development to validate syntax related problems.. This works, but for Runtime based Exceptions information is missing.
I am sending a logging object to context of VT so when I want to log something I use the $logging.log(contenttobelogged)
If some exception occurs during runtime, the exception trace does not contain any line numer details of Velocity template.
For that I have to put my log for each lines , so log makes code nasty. Can you guide me to log errors with proper line number?
Exception Trace :
Template Name #################### yes/po/POSSellerRSPGridData_JSON.vm
org.apache.velocity.exception.MethodInvocationException: Invocation of method 'get' in class java.util.ArrayList threw exception class java.lang.IndexOutOfBoundsException : Index: 1, Size: 1
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:308)
at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:202)
at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:345)
at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:135)
at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:94)
at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:109)
at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:94)
at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:344)
at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:153)
at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:94)
at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:344)
at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:153)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:271)
at org.apache.velocity.Template.merge(Template.java:296)
at ecnet.rd.core.template.TemplateResolver.merge(TemplateResolver.java:81)
at ecnet.rd.helper.YES_PO_Helper.mergerTemplateDetails(YES_PO_Helper.java:166)
Velocity tools 3.0 have a new tool, LogTool enable you to log error message inside template with error method
I frequently get what appears to be a stackoverflow error ;-) from YUICompressor. The following is the first part of thousands of error lines that come from attempting to compress a 24074 byte css stylesheet (not the "Caused by java.lang.StackOverflowError about 8 lines down):
iMac1:src jas$ min ../style2.min.css style2.css
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.yahoo.platform.yui.compressor.Bootstrap.main(Bootstrap.java:21)
Caused by: java.lang.StackOverflowError
at java.lang.Character.codePointAt(Character.java:2335)
at java.util.regex.Pattern$CharProperty.match(Pattern.java:3344)
at java.util.regex.Pattern$Branch.match(Pattern.java:4114)
... (plus 1021 more error lines)
The errors happen usually after adding a couple of lines to the file getting compressed. The css is fine, and works perfectly in the uncompressed format. I don't see a particular pattern to the types of selectors added to the file that cause the errors. In this case, adding the following selector to a previously compressible file resulted in the errors:
#thisisatest
{
margin-left:87px;
}
I am wondering if there is perhaps a flag to java to enlarge the stack that might help. Or if that is not the problem, what is?
EDIT:
As I was posting this question, it dawned on me that I should check the java command to see if there was a parameter to enlarge the stack. Turns out that it is -Xssn, where "n" is a parameter to indicate the stack size. Its default value is 512k. So I tried 1024k but that still led to the stackoverflow. Trying 2048k works however, and I think this could be the solution.
EDIT 2:
While I no longer use this method for minification any longer, to be more specific here is the full command (which I have set up as a shell alias), showing how the -Xss2048k parameter is used:
java -Xss2048k -jar ~/Documents/RepHunter/Website\ Materials/Code/Third\ Party\ Libraries/YUI\ Compressor/yuicompressor-2.4.8.jar --type css -o
As posted in my edit, the solution was to add the parameters to the java command. The clue was the error line at the 5-th "at" line, as follows:
at com.yahoo.platform.yui.compressor.Bootstrap.main(Bootstrap.java:21)
Caused by: java.lang.StackOverflowError
Seeing that the issue was a "StackOverlowError" ;-) gave the suggestion to try to increase the stack size. The default is 512k. My first try of 1024k did not work. However increasing it to 2048k did work, and I have had no further issues.