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.
Related
I was just trying to understand some blocked items from a thread dump:
"Thread-65" : 151 : RUNNABLE : cpu=36796875000 : cpuLoad= 0.29151857
BlockedCount:94117 BlockedTime:-1 LockName:null LockOwnerID:-1 LockOwnerName:null
WaitedCount:16 WaitedTime:-1 InNative:false IsSuspended:false at java.util.zip.ZipFile.open(ZipFile.java:-2)
at java.util.zip.ZipFile.(ZipFile.java:219)
at java.util.zip.ZipFile.(ZipFile.java:149)
at java.util.jar.JarFile.(JarFile.java:166)
at java.util.jar.JarFile.(JarFile.java:130)
at org.apache.tomcat.util.compat.JreCompat.jarFileNewInstance(JreCompat.java:188)
at org.apache.tomcat.util.compat.JreCompat.jarFileNewInstance(JreCompat.java:173)
at org.apache.catalina.webresources.AbstractArchiveResourceSet.openJarFile(AbstractArchiveResourceSet.java:316)
at org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntry(AbstractSingleArchiveResourceSet.java:96)
at org.apache.catalina.webresources.AbstractArchiveResourceSet.getResource(AbstractArchiveResourceSet.java:265)
at org.apache.catalina.webresources.StandardRoot.getResourceInternal(StandardRoot.java:281)
at org.apache.catalina.webresources.CachedResource.validateResource(CachedResource.java:97)
at org.apache.catalina.webresources.Cache.getResource(Cache.java:69)
at org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:216)
at org.apache.catalina.webresources.StandardRoot.getClassLoaderResource(StandardRoot.java:225)
at org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream(WebappClassLoaderBase.java:1067)
at java.lang.Class.getResourceAsStream(Class.java:2223)
at bsh.BshClassManager.getResourceAsStream(null:-1)
at bsh.classpath.ClassManagerImpl.getResourceAsStream(null:-1)
at bsh.BshClassManager.loadSourceClass(null:-1)
at bsh.classpath.ClassManagerImpl.classForName(null:-1)
at bsh.NameSpace.classForName(null:-1)
at bsh.NameSpace.getImportedClassImpl(null:-1)
at bsh.NameSpace.getClassImpl(null:-1)
at bsh.NameSpace.getClass(null:-1)
at bsh.Name.consumeNextObjectField(null:-1)
at bsh.Name.toObject(null:-1)
at bsh.Name.toObject(null:-1)
at bsh.NameSpace.get(null:-1)
at bsh.Interpreter.get(null:-1)
at bsh.Interpreter.getu(null:-1)
at bsh.Interpreter.(null:-1)
at bsh.Interpreter.(null:-1)
at bsh.Interpreter.(null:-1)
What I a not getting is the negative line number. Does it mean that that the source cannot be found?
Those are all beanshell classes. I'm guessing they do that to keep it from being confusing.
I'm guessing that they are using this as a "Trick" to remove those lines in some conditions (such as when you are running in the beanshell repl).
You could use that same trick to remove those lines from your dump.
This possibly related question How to get the complete log for bean shell scripts in jmeter
Suggested adding the debug() directive to beanshell get a less limited stack trace--perhaps if you did that then it would fill in those bsh stack lines?
I'm trying to build an uberjar using lein uberjar. During compiling, the following gets thrown:
Exception in thread "main" java.lang.NullPointerException, compiling:(/tmp/form-init8223412427040046857.clj:1:73)
at clojure.lang.Compiler.load(Compiler.java:7391)
at clojure.lang.Compiler.loadFile(Compiler.java:7317)
at clojure.main$load_script.invokeStatic(main.clj:275)
at clojure.main$init_opt.invokeStatic(main.clj:277)
at clojure.main$init_opt.invoke(main.clj:277)
at clojure.main$initialize.invokeStatic(main.clj:308)
at clojure.main$null_opt.invokeStatic(main.clj:342)
at clojure.main$null_opt.invoke(main.clj:339)
at clojure.main$main.invokeStatic(main.clj:421)
at clojure.main$main.doInvoke(main.clj:384)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.NullPointerException
at clojure.string$lower_case.invokeStatic(string.clj:217)
at clojure.string$lower_case.invoke(string.clj:213)
at kappa.joke_classifier$is_jokable_QMARK_.invokeStatic(joke_classifier.clj:32)
at kappa.joke_classifier$is_jokable_QMARK_.invoke(joke_classifier.clj:29)
at kappa.core$maybe_joke.invokeStatic(core.clj:47)
at kappa.core$maybe_joke.invoke(core.clj:45)
at clojure.core$run_BANG_$fn__7276.invoke(core.clj:7393)
at clojure.lang.PersistentVector.reduce(PersistentVector.java:341)
at clojure.core$reduce.invokeStatic(core.clj:6544)
at clojure.core$run_BANG_.invokeStatic(core.clj:7388)
at clojure.core$run_BANG_.invoke(core.clj:7388)
at kappa.core$run.invokeStatic(core.clj:58)
at kappa.core$run.invoke(core.clj:53)
at kappa.core$_main.invokeStatic(core.clj:66)
at kappa.core$_main.doInvoke(core.clj:61)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.Var.invoke(Var.java:375)
at user$eval5.invokeStatic(form-init8223412427040046857.clj:1)
at user$eval5.invoke(form-init8223412427040046857.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.eval(Compiler.java:6917)
at clojure.lang.Compiler.load(Compiler.java:7379)
... 14 more
The code using string/lower-case looks as follows:
(defn is-jokable? [msg]
(and
(> 30 (count msg))
(= :positive (.classify classifier (str/lower-case msg)))
(< 1 (:positive (.probabilities classifier (str/lower-case msg))))))
As can be seen from the stack trace, my -main function calls a function that eventually calls is-jokable, and str/lower-case seems to be called with nil. If I understand correctly this is because of the AOT compilation happening for uberjars, but I'm not quite sure why exactly this problem occurs... I've already tried to read up on AOT, but didn't find anything helpful. Can you explain the inner workings of AOT to me?
I'm almost embarrassed I have posted this, it must have been too late in the night... ;)
I got completely distracted by the compiling and invokeStatic hints in the stacktrace, and just now found that this was indeed an everyday bug where I expected a map to contain a key/value pair that wasn't existent, leading to nil being passed to the function in question.
Thanks for the helpful comments!
I'm using iText (in the latest version 5.4.4) for a generic print of user interfaces.
I have a Problem on some UIs, getting a NullPointerException:
23.10.2013 14:53:23.066 - ERROR -Container.doAdd()
com.itextpdf.text.DocumentException: java.lang.NullPointerException
...
Caused by: java.lang.NullPointerException
at com.itextpdf.text.pdf.ColumnText.setSimpleVars(ColumnText.java:312)
at com.itextpdf.text.pdf.ColumnText.setACopy(ColumnText.java:305)
at com.itextpdf.text.pdf.ColumnText.duplicate(ColumnText.java:294)
at com.itextpdf.text.pdf.PdfPCell.<init>(PdfPCell.java:255)
at com.itextpdf.text.pdf.PdfPRow.<init>(PdfPRow.java:131)
at com.itextpdf.text.pdf.PdfPTable.<init>(PdfPTable.java:261)
at com.itextpdf.text.pdf.ColumnText.setSimpleVars(ColumnText.java:347)
at com.itextpdf.text.pdf.ColumnText.setACopy(ColumnText.java:305)
at com.itextpdf.text.pdf.ColumnText.duplicate(ColumnText.java:294)
at com.itextpdf.text.pdf.PdfPCell.getMaxHeight(PdfPCell.java:968)
at com.itextpdf.text.pdf.PdfPRow.calculateHeights(PdfPRow.java:209)
at com.itextpdf.text.pdf.PdfPRow.getMaxHeights(PdfPRow.java:592)
at com.itextpdf.text.pdf.PdfPTable.getRowHeight(PdfPTable.java:990)
at com.itextpdf.text.pdf.PdfPTable.getRowHeight(PdfPTable.java:971)
at com.itextpdf.text.pdf.ColumnText.goComposite(ColumnText.java:1821)
at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:882)
at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:877)
at com.itextpdf.text.pdf.PdfPRow.splitRow(PdfPRow.java:736)
at com.itextpdf.text.pdf.ColumnText.goComposite(ColumnText.java:1662)
at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:882)
at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:877)
at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:866)
at com.itextpdf.text.pdf.PdfDocument.addPTable(PdfDocument.java:2602)
at com.itextpdf.text.pdf.PdfDocument.add(PdfDocument.java:727)
... 24 more
After days of debugging my own code and the code of iText, I think I found the responsible line in class com.itextpdf.text.pdf.PdfPRow line 699:
newCells[k].setColumn(null);
I removed this line in the iText-API and the NullPointer does not appear any more. Then the program generates a PDF again, but there still is a problem that there is to many vertical space, which i couldn't fix yet.
Does anybody have the same Problem? Is it a bug in iText?
Thanks for help!
MaKu
I am getting this strange error while executing the following code.
EncoderRequest encoderRequest = new EncoderRequest(sid,appTxnId,pfid,transactionType,"",isUpdatetype9,true);
I have checked all the parameter values are valid. I am using java7 plateform.
can any one have come across this situation, please help.
following is the part of stacktrace i am getting.
Caused by: java.lang.ClassFormatError: Illegal local variable table length 48 in method com.cmc.facts.encoder.EncoderRequest.<init>(JLjava/lang/String;Ljava/lang/Long;Lcom/cmc/facts/enums/TransactionType;Ljava/lang/String;ZZ)V at com.cmc.facts.nist.NistReaderModel.preprossingOfNistFile(NistReaderModel.java:180) at com.cmc.facts.action.interstate.InterStateAction.uploadFIIF(InterStateAction.java:645) ... 115 more
There have been previous reports of the same error, on Junit tests and similar..
For them, adding the JVM arg -XX:-UseSplitVerifier seemed to work
Have a look at this article
You can also do this config :
Add -noverify in your jvg args
For ant config you can do : <jvmarg value="-noverify"/>
You can follow the link for more details on why we need to do this.
I'm working with a legacy Java app that has no logging and just prints all information to the console. Most exceptions are also "handled" by just doing a printStackTrace() call.
In a nutshell, I've just redirected the System.out and System.error streams to a log file, and now I need to parse that log file. So far all good, but I'm having problems trying to parse the log file for stack traces.
Some of the code is obscufated as well, so I need to run the stacktraces through a utility app to de-obscufate them. I'm trying to automate all of this.
The closest I've come so far is to get the initial Exception line using this:
.+Exception[^\n]+
And finding the "at ..(..)" lines using:
(\t+\Qat \E.+\s+)+
But I can't figure out how to put them together to get the full stacktrace.
Basically, the log files looks something like the following. There is no fixed structure and the lines before and after stack traces are completely random:
Modem ERROR (AT
Owner: CoreTalk
) - TIMEOUT
IN []
Try Open: COM3
javax.comm.PortInUseException: Port currently owned by CoreTalk
at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:337)
...
at UniPort.modemService.run(modemService.java:103)
Handling file: C:\Program Files\BackBone Technologies\CoreTalk 2006\InputXML\notify
java.io.FileNotFoundException: C:\Program Files\BackBone Technologies\CoreTalk 2006\InputXML\notify (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
...
at com.gobackbone.Store.a.a.handle(Unknown Source)
at com.jniwrapper.win32.io.FileSystemWatcher.fireFileSystemEvent(FileSystemWatcher.java:223)
...
at java.lang.Thread.run(Unknown Source)
Load Additional Ports
... Lots of random stuff
IN []
[Fatal Error] .xml:6:114: The entity name must immediately follow the '&' in the entity reference.
org.xml.sax.SAXParseException: The entity name must immediately follow the '&' in the entity reference.
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
...
at com.gobackbone.Store.a.a.run(Unknown Source)
Looks like you just need to paste them together (and use a newline as glue):
.+Exception[^\n]+\n(\t+\Qat \E.+\s+)+
But I would change your regex a bit:
^.+Exception[^\n]++(\s+at .++)+
This combines the whitespace between the at... lines and uses possessive quantifiers to avoid backtracking.
We have been using ANTLR to tackle the parsing of logfiles (in a different application area). It's not trivial but if this is a critical task for you it will be better than using regexes.
I get good results using
perl -n -e 'm/(Exception)|(\tat )/ && print' /var/log/jboss4.2/debian/server.log
It dumps all lines which have Exception or \tat in them. Since the match is in the same time the order is kept.