[gs-bugs] [Bug 692247] New: /unregistered in --.poppdf14devicefilter--

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Wed Jun 1 00:51:12 UTC 2011


http://bugs.ghostscript.com/show_bug.cgi?id=692247

           Summary: /unregistered in --.poppdf14devicefilter--
           Product: Ghostscript
           Version: 9.02
          Platform: PC
        OS/Version: Windows 7
            Status: NEW
          Severity: normal
          Priority: P4
         Component: PDF Interpreter
        AssignedTo: alex.cherepanov at artifex.com
        ReportedBy: mattwalkenhorst at fastmail.fm
         QAContact: gs-bugs at ghostscript.com
   Estimated Hours: 0.0


Created an attachment (id=7553)
 --> (http://bugs.ghostscript.com/attachment.cgi?id=7553)
Zipped PDF that causes the Error: /unregistered in --.poppdf14devicefilter--

When running the following command to render a pdf to a jpeg using gs9.02

gswin64c.exe -sDEVICE=jpeg -sOutputFile=C:\gm\PDF-JpegOut\testtrans.jpg
C:\gm\PDF-JpegOut\testtrans.pdf

The process proceeds to quickly consume 2Gb of memory before exiting with the
following error:

Error: /unregistered in --.poppdf14devicefilter--
Operand stack:
   --dict:12/21(L)--   1   11   3
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   1910   1   3   %oparray_pop  
1909   1   3   %oparray_pop   1893   1   3   %oparray_pop   --nostringval--  
--nostringval--   2   1   1   --nostringval--   %for_pos_int_continue  
--nostringval--   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1159/1684(ro)(G)--   --dict:1/20(G)--   --dict:82/200(L)--  
--dict:82/200(L)--   --dict:108/127(ro)(G)--   --dict:295/300(ro)(G)--  
--dict:23/30(L)--   --dict:6/8(L)--   --dict:22/40(L)--   --dict:3/5(L)--  
--dict:7/15(L)--   --dict:1/1(ro)(G)--
Current allocation mode is local
Last OS error: No such file or directory

This happens with the 32 bit 9.02 as well. If the -dNOTRANSPARENCY parameter is
used, the memory leak does not occur and a jpeg is created, albeit rendered
incorrectly as the transparency was not processed. e.g.:

gswin64c.exe -sDEVICE=jpeg -sOutputFile=C:\gm\PDF-JpegOut\testtrans.jpg
-dNOTRANSPARENCY C:\gm\PDF-JpegOut\testtrans.pdf


Using a previously installed version of gs8.71, this error does not occur. The
following renders the jpeg correctly, although it takes a fair while:

gswin32c.exe -sDEVICE=jpeg -sOutputFile=C:\gm\PDF-JpegOut\testtrans.jpg
C:\gm\PDF-JpegOut\testtrans.pdf

I will attempt to upload the testtrans.pdf as a zipped attachment, but if that
fails I can be contacted by email if anyone would like it.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list