| Summary: | -dNODISPLAY result in crash | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | thebudget72 |
| Component: | Regression | Assignee: | Default assignee <ghostpdl-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | till.kamppeter |
| Priority: | P4 | ||
| Version: | 9.56.1 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: | Article1.pdf | ||
|
Description
thebudget72
2022-08-31 11:30:36 UTC
(In reply to thebudget72 from comment #0) > $ gs-9561 -q -dNOSAFER -dNODISPLAY -c '(article1.pdf) (r) file runpdfbegin > pdfpagecount = quit' > 32 > free(): double free detected in tcache 2 > Aborted (core dumped) You're going to have to attach the file article1.pdf before we can investigate this. Also, if you're going to access the PDF file programatically, you should close the PDF interpreter before you execute quit. I don't think this has anything to do with -dNODISPLAY, that simply alters the way the memory is used. Most of the time you won't get the error, but if the memory happens to be laid out in a particular way, you do. I suspect this has already been fixed, but I'll need the actual input file to be certain. Created attachment 23103 [details]
Article1.pdf
Attached article1.pdf for further investigation. How do I close the PDF interpreter before I execute quit? (In reply to thebudget72 from comment #4) > How do I close the PDF interpreter before I execute quit? Call runpdfend. If, as I suspect, this has already been fixed, that will be enough to resolve the problem in 9.56.1. You could also try the 10.00.0 release candidate which is here: https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/tag/gs10.0.0rc1 The functions and operators for scripting the PDF interpreter are documented: https://ghostscript.com/doc/current/Language.htm#PS_functions Indeed calling runpdfend fixes it :) ``` $ gs-9561 -q -dNOSAFER -dNODISPLAY -c '(article1.pdf) (r) file runpdfbegin pdfpagecount = runpdfend quit' 32 ``` (In reply to thebudget72 from comment #6) > Indeed calling runpdfend fixes it :) That's excellent, thanks for trying it. Unfortunately I cannot reproduce the problem locally. This isn't entirely surprising as it is so sensitive to the exact memory locations and the way garbage collection in Ghostscript works. It will also be affected by how the binary was built and assuming you are using a package rather than building from source you will almost certainly be using system shared libraries instead of static linking. The exact toolchain (which C compiler, which version of the compiler etc) will cause the problem to appear/disappear/move around as well unfortunately However, I think that this is effectively a duplicate of bug #705210 (but exhibiting slightly different symptoms) and should be fixed with commit 2a54c676fe2e5e7b5415302e7a35e34fc3e9db87 It is difficult to be certain, as noted above, but it looks awfully similar to me. Given that you now have a work-around, and what I believe to be the underlying problem has been resolved I'm going to close this as fixed. If you still get the problem with the 10.00.0 release please reopen the report and I'll try again to reproduce it. *** Bug 705855 has been marked as a duplicate of this bug. *** |