When using Ghostscript 9.56 (64 bits) it will randomly crash when using the new PDF engine. I made an example C# overhere (yes I used the official API) --> https://github.com/Sicos1977/GhostscriptConsole When running this test code 100 times with the parameter -dNEWPDF=false it runs without any problems. When running the same code with -dNEWPDF=true it crashes on the call to GSAPI.gsapi_delete_instance(gsInstance); after about 2 to 3 runs.
It would be very much preferable if you were to use our executable to report problems, rather than creating a custom C# application. I am not a C# developer and the use of it significantly slows me down. Your application builds a PostScript program which it then executes, you could just as easily take that program and run it through the standard executable. Your application also relies upon a fixed location for the test file and to write the PostScript program to, it would have been helpful to point this out, and to mention where alterations (such as -dNEWPDF=false) need to be made. I can duplicate a crash using your application, but cannot find any way to debug the DLL by starting from C#. I'll look into this at some point but it's going to take me some considerable time to figure out how to debug the Ghostscript code by starting from C#. At a guess, the problem is related to the fact that you are leaving the page dictionary on the stack and not closing the PDF interpreter on each run. I suspect that eventually that catches up with you. However I can't possibly tell until I can actually get to the point of debugging Ghostscript in this environment.
Ken, What I always do with a new release of Ghostscript is performance test. Most of the code in the example program is just copied from some example files from Artifex. Normally I would not use a fixed location, that was just used to show that the program craches after a few executions. It also crashes when using a new location everytime. For example create a temp folder with a GUID as name. I would expect that the call to gsapi_delete_instance(gsInstance) would free all resources because it is unloading everything but that seems not to happen. When using the gs executable a process is created every time so that is not simular as reusing the DLL from a C# program. If you need any help in C# then let me know and I will build it for you ... For now have a nice weekend.
Created attachment 22393 [details] Crash screenshot
Ghostscript also crashes when using gswin64c with this as the command line gswin64c.exe -q -dQUIET -dNEWPDF=true --permit-file-all=d:\test\test.pdf d:\test\test_pdfinfo.ps Just rerun the program a few time. After about 2 times it crashes
When adding the command pdfclose at the end the bug is resolved. I also tried to use runpdfend but that always gives me this error Error: /invalidrestore in --restore-- Operand stack: --dict:5/14(L)-- --dict:5/14(L)-- --nostringval-- --nostringval-- Execution stack: %interp_exit .runexec2 --nostringval-- restore --nostringval-- 2 %stopped_push --nostringval-- restore restore false 1 %stopped_push 1990 1 3 %oparray_pop 1989 1 3 %oparray_pop 1977 1 3 %oparray_pop 1833 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- restore --nostringval-- 2 %stopped_push --nostringval-- restore 1894 3 4 %oparray_pop restore 1875 3 4 %oparray_pop restore Dictionary stack: --dict:763/1123(ro)(G)-- --dict:0/20(G)-- --dict:80/200(L)-- --dict:19/20(L)-- Current allocation mode is local Last OS error: Permission denied Current file position is 3605 GPL Ghostscript 9.56.0: Unrecoverable error, exit code 1 It almost looks like if something is keeping a lock on the PDF file
I'm just a novice in postscript programming but after clearing the stack first and then runpdfend the bug is also fixed. clear runpdfend
(In reply to Kees van Spelde from comment #4) > Ghostscript also crashes when using gswin64c with this as the command line > > gswin64c.exe -q -dQUIET -dNEWPDF=true --permit-file-all=d:\test\test.pdf > d:\test\test_pdfinfo.ps > > Just rerun the program a few time. After about 2 times it crashes That is, actually, helpful. Because we don't need to run C# and that means we can debug using our own code and on Linux, which is helpful for tracing memory issues. (In reply to Kees van Spelde from comment #5) > When adding the command pdfclose at the end the bug is resolved. Yes, as I said, your current PostScript program doesn't terminate the PDF interpreter. Not something I specifically tested. > I also tried to use runpdfend but that always gives me this error Because, as I also said, your program leaves a dictionary on the stack for each page. You can't restore while those dictionaries are present and runpdfend executes a restore. > It almost looks like if something is keeping a lock on the PDF file No just the presence of the dictionaries. Again, when I have time, I'll look into why failing to terminate the PDF interpreter should lead to a memory problem. In the meantime you clearly have a work-around for the problem.
I'm not in a hurry, I'm happy that your comment about the dictionaries pointed me in the right direction to solve the issue. Thanks again.
I believe this is fixed with commit 2a54c676fe2e5e7b5415302e7a35e34fc3e9db87 Running the supplied C# application (with some path and argument modification) did not complete previously and now completes all 100 executions, even without cleaning up the PostScript operand stack.