search

zippy1978 / ghost4j

Java wrapper for Ghostscript C API + PS/PDF document handling API
http://www.ghost4j.org
GNU Lesser General Public License v3.0
64 stars 38 forks source link

Cannot initialize Ghostscript interpreter. Error code is -100 #72

Open EggSoup opened 3 years ago

EggSoup commented 3 years ago

Hello, I encountered the following situation when using ghost4j as a tool for converting pdf images: We call it in a timed task. The program can run normally at the beginning, but after running for a period of time, it will occasionally report the error "Cannot initialize Ghostscript interpreter. Error code is -100" that cannot be initialized, and it will keep reporting after running for a while. This error cannot be executed normally. Environmental description: Server: Centos7.6 ghostscript: 9.25 and 9.53.3 JDK: 1.8 I don’t know if anyone has answered it. If anyone encounters the same problem, you can advise, thank you.

Fitnerd commented 3 years ago

Same issue here!

MasterEugene commented 3 years ago

I have same problem. When i used jdk1.6 - works fine. But when 1.7 or higher - "Error code is -100"

jimirich commented 1 year ago

I have encountered the same error, but I'm not convinced that the cause is the same. After spending a few days trying to figure it out, I've narrowed down the issue a bit. I have created a Postscript file that will fail PDF conversion every time when run through ghost4j. However, it is perfectly valid Postscript and running it through a PDF conversion on the command line works.

I discovered that when the initialize method in the Ghostscript class calls GhostscriptLibrary.instance.gsapi_init_with_args() bytes are being dropped. ghost4j sets up stdin with the contents of my Postscript file and I have verified that that part is perfectly fine. But then when gsapi_init_with_args() is called two bytes are dropped. I tested this by finding exactly what two bytes from my input file were dropped, and then in that spot added "XX" to my file (which resulted in invalid Postscript) but those two bytes are dropped and the result is a valid PDF.

I then tried using a different Postscript file as input and looking at the bytes in the positions in the new file as in my original test file. But the bytes weren't being dropped. So something about my original test file causes two bytes to be dropped in positions 261998 and 261999 of the original input file.

I suspected a possible problem with Ghostscript, so I upgraded gs from version 9.55.0 to 9.56.1 and then again to 10.0.0 but that didn't make any difference. Then I looked at trying to use JNI instead of JNA but didn't make any headway there. I added some additional logging to my local copy of ghost4j to log parameters, switch from java.util.Date to java.time.LocalDate, and update dependencies to the latest versions. Still no real solution. I suspect some problem lies in the JNA code, but I couldn't pinpoint anything more specific.

jimirich commented 1 year ago

I created my own fork of ghost4j that contains the changes I've made while trying to track this problem down. The significant differences are that I've updated to the latest dependencies and also changed the compiler to use Java 17. The logger also prints out (nearly) the same information that you get when you run ghostscript from the command line.