You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running epubcheck on an epub with a large opf file (13k+ lines, 841k) it throws the following StackOverflowError. Unfortunately I can't share the epub since it isn't public content.
epubcheck-4.2.6$ java -jar epubcheck.jar foobar.epub
Validating using EPUB version 3.2 rules.
java.lang.StackOverflowError
at java.base/java.util.LinkedList.unlinkFirst(LinkedList.java:178)
at java.base/java.util.LinkedList.poll(LinkedList.java:679)
at com.adobe.epubcheck.opf.XRefChecker.checkReadingOrder(XRefChecker.java:538)
at com.adobe.epubcheck.opf.XRefChecker.checkReadingOrder(XRefChecker.java:599)
at com.adobe.epubcheck.opf.XRefChecker.checkReadingOrder(XRefChecker.java:599)
I've seen that the recommended fix is to increase xss, but is there a way to change epubcheck to not require as much stack size?
This particular opf file has 6000+ <itemref> elements in the <spine>, and if I'm reading correctly it looks like these are evaluated using a recursive algorithm.
Question: Would changing the above to use iteration instead of recursion potentially decrease the required stack size?
The text was updated successfully, but these errors were encountered:
We are having a similar issue, which is blocking some content ingestion. Looking at the code, the iterative version seems to be about one line shorter - I don't understand why this is using recursion at all. Java is not good at tail recursion optimizations. @rdeltour is this something we can look at in 5.0? The fix seems reasonably straightforward, do you want a PR?
When running epubcheck on an epub with a large opf file (13k+ lines, 841k) it throws the following StackOverflowError. Unfortunately I can't share the epub since it isn't public content.
I've seen that the recommended fix is to increase xss, but is there a way to change epubcheck to not require as much stack size?
This particular opf file has 6000+
<itemref>
elements in the<spine>
, and if I'm reading correctly it looks like these are evaluated using a recursive algorithm.Question: Would changing the above to use iteration instead of recursion potentially decrease the required stack size?
The text was updated successfully, but these errors were encountered: