Bug 695335

Created attachment 11024 [details]
output from ghostscript showing errors

This shows the strange errors that GhostScript reports intermittently.

For this test, I ran a script that compresses 16 pdfs in two steps (compress first 8, then when done, compress second 8).  I ran that script 10 times.

As I keep saying to people, using the predefined PDFSETTINGS is never a terribly clever idea when making a bug report as that sets a whole load of stuff. It would be better to investigate the problem by changing the settings fro default one at a time to localise the one which causes a failure.

In this case its almost certainly the color conversion strategy.

Please be aware that pdfwrite neither 'combines' nor 'compresses' PDF files. It completely interprets the input PDF file to graphics primitives and then constructs a new file from the graphic primitives. The new file bears no relation to the original other than its visual appearance.

Since you haven't supplied any test files, nor indication that there is an actual problem other than the warnings, I'm going to assume there is no actual problem, in which case this looks very much like a duplicate of bug #695306 and I'm resolving this as a duplicate.

If you feel this is incorrect you can reopen it.

*** This bug has been marked as a duplicate of bug 695306 ***

Unfortunately, I can provide you with input or output files as they contain confidential data that I am not allowed to release.

I don't understand why you say this is not combined and compressed... since 20,000+ PDFs totaling almost 6GB can be run through a single instance of GhostScript using the settings I provided without any errors reported and I get a 150MB single PDF file that contains all those pages in all the original.  That sure seems like combined and compressed to me.

Secondly, I am concerned over these error messages which only happen when I run multiple copies of GhostScript on the same machine (even when using different input and output files for each running copy).

I don't think this is a duplicate since it only happens intermittently when more than one copy is running.  With only one copy running, the issue never happens.

(In reply to wJjX27RXegef from comment #4)
> Unfortunately, I can provide you with input or output files as they contain
> confidential data that I am not allowed to release.
> 


Typo... should have been ' I cannot provide you '

(In reply to Ken Sharp from comment #2)
> As I keep saying to people, using the predefined PDFSETTINGS is never a
> terribly clever idea when making a bug report as that sets a whole load of
> stuff. It would be better to investigate the problem by changing the
> settings fro default one at a time to localise the one which causes a
> failure.
> 
> In this case its almost certainly the color conversion strategy.

This is the very first time I've ever heard of this.  In fact, I have never heard of any recommendations on how to use this product in either the do use or the do not use category.

I should add that the documentation for this product is very poor for users like myself who have no experience with the product.

I will look into the the PDFSETTINGS are and see how to switch these to individual settings.

Since you cannot provide the files that cause the failure, and since this does
look like it might be referencing bad memory, please perform the following:

1) update to the latest source from our git repository.
2) Build a debug version (linux: make debug)
3) run the test with debugbin/gs -Z@\$\? ...

Also, you may want to try running gs under valgrind to see if the code is using
uninitialized or freed memory.

4) report the results here.

Note that you need not re-open the bug since we still see posts to bugs that
are "RESOLVED", but if the results seem to show something useful, you may want
reopen the bug.