-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running epubcheck on an epub with a large opf file (13k+ lines) results in a StackOverflowError #1358
Comments
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? [Edit]: Oh, the reporter is us :) Hi Matt! |
FWIW, I think the recursion can be replaced with |
hi @myork and @bduga. Thanks for the report! I'll look into it for v5.0.0, but need to merge the ongoing work first, as this code has been refactored and merging it early will create conflicts.
Would you be able to send the EPUB privately? I can possibly sign an NDA if needed. |
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: