This can also be a problem in or with the PdfHandler extensions.

Bryan.TongMinh wrote:

My guess would be out-of-memory. Is ImageMagick able to to its memory efficient jpeg resizing algorithm when reading from stdin?

Id guess gs being the thing oom.

The problem is, that the PDF is probably not correct and the GhosScript puts out some messages

wget "https://upload.wikimedia.org/wikipedia/commons/a/a1/%D0%95%D1%82%D0%BD%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D1%96%D1%87%D0%BD%D0%B8%D0%B9_%D0%B7%D0%B1%D1%96%D1%80%D0%BD%D0%B8%D0%BA_%D0%A2.28.pdf" --output-document="testfile.pdf"
# process by gs
gs -sDEVICE=jpeg -sOutputFile=testfile.jpg -dFirstPage=1 -dLastPage=1 -r150 -dBATCH -dNOPAUSE -q 'testfile.pdf'
 **** Warning: glyf overlaps cmap, truncating.
 **** Warning: glyf overlaps cmap, truncating.
 **** Warning: glyf overlaps cmap, truncating.
 **** Warning: glyf overlaps cmap, truncating.
 **** Warning: glyf overlaps cmap, truncating.

ImageMagick consumes these (via | pipe) and consequently ImageMagick fails to process the image, because the text-warning messages are rerouted to ImageMagick. The warning messages are printed to stdout.

I have the same issue https://www.mediawiki.org/wiki/Extension_talk:PdfHandler#Warning_Messages_in_gs_subprocess_fail_image_creation_52766

The solution would be a feature request:

1. gs should write an intermediary image file
2. convert uses this intermediary image file instead of pipe input

See also http://bugs.ghostscript.com/show_bug.cgi?id=695600#c3.

I can't reproduce the warnings on a stock mediawiki vagrant VM, sadly, but avoiding the pipe sounds like a sensible thing to do anyway.

I have even tried in my localhost and run perfectly there is no error displaying I think previously this was due to "-dSAFER" actually a bug in ghostscript it can be checked here https://bugs.ghostscript.com/show_bug.cgi?id=691780 , If anyone reproduces please specify?