[sjallard]

Hello, and thank you Doistu for your plugins !

I've self-solved my problem, but I'll leave my question below in case it helps someone else get his answer quicker

I did read you post, but I hadn't caught the link between the "is32bit" flag and the JVM StackOverflow error. I just assumed a 32bit flag doesn't concern my configuration and could even bring other problems/limitations if I had used it, and so I went to modify your code instead, to implement exactly your logic about the overflow prevention .

If that flag doesn't change anything important about 32/64 architecture but is more (or only?) targeted at the JVM overflow problem, could it be maybe renamed to reflect this in a future release ?

My original question :

I'm all good with every requirements (java, python, sigil) and the epubcheck update, but I got the following java.lang.StackOverflowError error :

Spoiler:

Statut : failed

EPUBCheck 5.1.0 en cours d'exécution ... veuillez patienter.
Erreur de java.
java.lang.StackOverflowError
at com.thaiopensource.relaxng.pattern.ChoiceNameClass .contains(ChoiceNameClass.java:16)
at com.thaiopensource.relaxng.pattern.AnyNameExceptNa meClass.contains(AnyNameExceptNameClass.java:14)
at com.thaiopensource.relaxng.pattern.OverlapDetector .checkOverlap(OverlapDetector.java:68)
at com.thaiopensource.relaxng.pattern.DuplicateAttrib uteDetector.checkAttributeOverlap(DuplicateAttribu teDetector.java:35)
at com.thaiopensource.relaxng.pattern.DuplicateAttrib uteDetector.addAttribute(DuplicateAttributeDetecto r.java:30)
etc. etc.

I found the following advice to augment the JVM stack size with phind.com :

Spoiler:

The java.lang.StackOverflowError you're encountering is due to the Java Virtual Machine (JVM) running out of stack space. This typically happens when there is a recursive call that goes too deep. In your case, it appears to be happening during the execution of the EPUBCheck tool within the Sigil plugin.

According to the EPUBCheck troubleshooting documentation, if EPUBCheck crashes with a StackOverflowError, you can adjust the thread stack size of your JVM by using the -Xss option of the java command. For instance, you could increase the stack size to 1024 kilobytes with the command java -Xss1024k -jar epubcheck.jar.

However, in your case, you're running EPUBCheck via a Python script, specifically the jar_wrapper function in your script. You might need to modify this function to include the -Xss1024k option when calling the java command.

Please note that increasing the stack size might not always solve the problem, especially if the underlying issue is a deeply nested recursion or a large amount of local variables. Also, be aware that increasing the stack size might lead to excessive memory usage if the stack size is set too high 2.

Lastly, remember that the -Xss option needs to be passed to the JVM before it starts, so it can't be set via Java code 2.

So I've tried the following mod of your plugin (line 447) :

    #----------------------------------------------------------------------
    # define epubcheck command line parameters
    #----------------------------------------------------------------------
    if is32bit:
        args = [java_path, '-Dfile.encoding=UTF8', '-Xss1024k', '-jar', epc_path, epub_path, '-q', '--json', '-']
    else:
        # !!! debug java.lang.StackOverflowError with -Xss1024k flag...
        # args = [java_path, '-Dfile.encoding=UTF8', '-jar', epc_path, epub_path, '-q', '--json', '-'] 
        args = [java_path, '-Dfile.encoding=UTF8', '-Xss1024k', '-jar', epc_path, epub_path, '-q', '--json', '-']

And it did work.

Is there anything else I could have done ? If no, maybe that could be an option to add via gui or via the json file ?
... Oh, I see : it is already implemented, through the "is32bit": true flag