Bug 690258 - can't read pdf because of unbalanced >>
Summary: can't read pdf because of unbalanced >>
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: 8.63
Hardware: PC Windows XP
: P4 blocker
Assignee: Alex Cherepanov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-29 03:05 UTC by Harry McKame
Modified: 2009-02-06 01:18 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
VCVARS32.BAT (989 bytes, text/plain)
2009-02-04 09:03 UTC, Ray Johnston
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harry McKame 2009-01-29 03:05:24 UTC
I encountered a PDF file that works fine on Adobe Reader but doesn't display in
GhostScript.
The error message I'm getting is:
**** File has an unbalanced >> (close dictionary).
**** Incorrect object count in object stream.
I can't manage to copy the rest of the text from the GhostScript window, so I
can't include it all here (except the above message that I typed-in by hand).
I would like to find out where in the pdf file is the error, but don't see how to.
I've recompiled the sources in debug mode, but although I can break-point on the
above error message, understanding the code is not very easy.
Even if the unbalanced >> is true, why can't GhostScript continue in spite of
this error? Recovering from such an error should be easy.
Comment 1 Ken Sharp 2009-01-29 03:26:24 UTC
In general Ghostscript will continue to process PDF files after errors, when
this is possible. Note that you have quoted two faults, the first is an
unbalanced dictionary mark (>>) the second is an incorrect object count in an
object stream. These may occur in the same place, or may not. 

Object streams are a method for compressing additional types of objects in a PDF
file for greater overall compression and smaller file size.

An object stream starts with an index of objects and their byte offset within
the stream. Unlike 'normal' PDF objects, these are not preceded by their object
definition (eg 2 0 obj), but are simply the contents of the objects, run
together. It can be difficult to know where one object stops and another starts. 

We can tell that something is wrong, but not necessarily whether it is the
content or the index which is incorrect. We can't scan the content looking for
'<index> <generation> obj...endobj' constructions to rebuild the index, which
can be done for damaged xref tables, because the content of an object stream
doesn't contain these markers.

Now, as to where the error is, if you run GS with '-dPDFDEBUG' on the command
line you should be able to see from the GS window which object it is processing
when the error occurs. Since the object stream is compressed, it would be hard
to fix it, and in order to 'see' the problem you will have to decompress the
content of the object stream.

That's about all that can be said without looking at the actual PDF file. If
you'd like someone to look at it, you'll need to attach it to this bug report.
If you want you can mark it as private immediately after you attach it, which
will prevent anyone except Artifex employees and contractors from accessing it.

Comment 2 Harry McKame 2009-01-29 08:48:42 UTC
Created attachment 4766 [details]
bug_balanced.pdf
Comment 3 Harry McKame 2009-01-29 08:54:20 UTC
Alex,
Thanks for the useful answer.
I've uploaded the file for examination per instructions.
I note that GhostScript cannot read the second and following pages, while
Acrobat does so without a hiccup.
Regards
Harry McKame
Comment 4 Ken Sharp 2009-01-29 09:12:10 UTC
Harry,

it looks like this may be a bug which has already been fixed. When I run the PDF
file through the most recent revision of Ghostscript on my Windows box here it
completes without complaint. You are correct that Acrobat also does not
complain, and usually if it 'fixes' a file it offers to save it when you close
the file, which it doesn't do in this case.

I don't know exactly how you are invoking Ghostscript, but running gswin32 on
Windows and dropping the file I can see all 6 pages.

We are doing a new release of Ghostcript right now, if release candidate 2
proves satisfactory it should be released on 1st February (West Coast US).
Binaries should be available for download pretty much immediately after release.

I'd suggest you either pick up the new version then or, if you are comfortable
with recompiling Ghostscript from source, pull a copy of the latest sources from
the Ghostscript Subversion source repository.

If this doesn't resolve the issue for you please feel free to reopen the bug.
Comment 5 Harry McKame 2009-02-04 02:33:00 UTC
I've downloaded and compiled version 8.64 and have tried it with the attached
file. The results are half-encouraging: The error doesn't arrive any more in
gswin32.exe, but an error still arrives in gsdll32.dll!
By breakpoint on gsdll_stdout(), I've accumulated the following error text
(which might be a bit mangled as regarding end of lines):

While reading gs_res.ps:
Error: /rangecheckes.ps:
in --getinterval--s.ps:
Operand stack:
   (gs_res.ps)   (C:\\Program Files\\GhostScript\\ghostscript-8.64\\Resource)  
()   0   1
Execution stack:
interp_exit   --nostringval--   --nostringval--   --nostringval--  
%array_continue   --nostringval--   --nostringval--   --nostringval--   false  
1   %stopped_push   --nostringval--   --nostringval--   --nostringval--  
%array_continue   --nostringval--
Dictionary stack:
   --dict:773/1123(G)--   --dict:62/200(L)--   --dict:773/1123(G)--  
--dict:165/251(G)--   --dict:773/1123(G)--   --dict:23/40(ro)(G)
--Last OS error: No such file or directory
Current file position is 11413
251(G)--   --dict:773/1123(G)
Unrecoverable error: undefinedt OS error: No such file or directory
Current file position is 11413
251(G)--   --dict:773/1123(G) 7
in .uninstallpagedevice
finedt OS error: No such file or directory
Current file position is 11413
251(G)--   --dict:773/1123(G) 7
Operand stack:
    gs_res.psedt OS error: No such file or directory
Current file position is 11413
251(G)--   --dict:773/1123(G) 7
  C:\Program Files\GhostScript\ghostscript-8.64\Resourcer directory
Current file position is 11413
251(G)--   --dict:773/1123(G) 7
  C:\Program Files\GhostScript\ghostscript-8.64\Resourcer directory
Current file position is 11413
251(G)--   --dict:773/1123(G) 7
  0:\Program Files\GhostScript\ghostscript-8.64\Resourcer directory
Current file position is 11413
251(G)--   --dict:773/1123(G) 7
 1:\Program Files\GhostScript\ghostscript-8.64\Resourcer directory
Current file position is 11413
251(G)--   --dict:773/1123(G) 7

Further info:
I've in the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript\8.64" the
following values:
GS_DLL: C:\Program Files\GhostScript\ghostscript-8.64\bin\gsdll32.dll
GS_LIB: C:\Program Files\GhostScript\ghostscript-8.64\lib;c:\program
files\GhostScript\fonts;C:\Program Files\GhostScript\ghostscript-8.64\Resource

I've no other subkeys than 8.64 under "HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript".

Your input will be appreciated.
Comment 6 Ken Sharp 2009-02-04 03:05:34 UTC
I'm afraid that looks like a problem compiling the sources, GS appears to be
complaining that it can't find gs_res.ps. 

You haven't stated the command line you are using so its difficult to be sure
what is going on. You can check and see if the file is present in
/gs/Resource/Init/gs_res.ps (which it should be), but this file is supposed to
be compiled into the executable in a ROM file system.

As an experiment, in the command line window, set GS_LIB= and then try launching
gswin32 from that command line window, not the GUI. I suspect there may be some
problem with your installation and this 'may' narrow it down.

You could also try running some of the files in the 'examples' folder, and
perhaps some other PDF files if you have any, just to check whether your
installation is working at all.

Comment 7 Harry McKame 2009-02-04 03:25:02 UTC
I'm afraid that my compilation was ok as regarding gswin32.exe, but not for
gsdll32.dll - it is totally non-functional.

As all my knowledge about compiling ghostscript is entirely contained in the string:
  nmake -f psi\msvc32.mak MSVC_VERSION=6 DEVSTUDIO="C:\Program Files\Microsoft
Visual Studio"
I have no idea why the above did miscompile my gsdll32.dll.

But I wonder if you could point me to a working 8.64 Windows binary release,
please ?
Comment 8 Ken Sharp 2009-02-04 06:56:05 UTC
I'm afraid there doesn't seem to be a binary release for Windows yet. Are you
really using Microsoft visual C 6 ? I presume that's the original version of
Microsoft Visual Studio, released back in 1998 and superseded by Visual Studio
.NET in 2002 ?

I would try :

nmake -f psi/msvc32.mak clean
nmake -f psi/msvc32.mak 

which should rebuild everything for you, and should auto-detect the version of
VC++ based on the version of nmake. (You may need to run the msvcvars.bat file
in order to get the PATH environment variable correct so that Windows can find
the build tools)

Failing that, there is normally a binary release available soon after the
sources are posted, but they were only released yesterday.
Comment 9 Harry McKame 2009-02-04 08:41:55 UTC
1. I don't find msvcvars.bat anywhere in the versions 8.64 or 8.63 (or anywhere
on my hard disks).
2. I do have VS6 installed, but also VS2005. "nmake -f psi/msvc32.mak" manages
to abort VS2005 on the first compile of .\base\genarch.c :
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 8\VC\bin\c
l.EXE"' : return code '0xc0000135'

It seems like I must wait for the binary release. It should perhaps be noted
somewhere that :
a. The 8.64 source release doesn't correctly build gsdll32.dll on VS6,
b. that it provokes an abort in VS2005, and that
c. msvcvars.bat is missing.
Comment 10 Ray Johnston 2009-02-04 09:01:49 UTC
I built 8.64 with MSVC 6 and MSVC 8.
The command line I used (from a MS-DOS prompt) to build with 6 was:

vcvars32.bat

nmake -f psi/msvc32.mak MSVC_VERSION=6 > make6.log 2>&1

I will attach the 'vcvars32.bat' from my system in case that helps. This is
what was created automatically when I installed Visual Studio 6.

Note that for MSVC 8, the batch file that sets up the environment variables is
vsvars32.bat (also created automatically during the install).
Comment 11 Ray Johnston 2009-02-04 09:03:24 UTC
Created attachment 4777 [details]
VCVARS32.BAT

Sample vcvars32.bat from my system (installation directories may vary).
Comment 12 Ken Sharp 2009-02-04 09:10:19 UTC
1. msvcvars.bat is (or was) part of the Visual Studio distribution. When
executed in a command line window it configures the environment to run the
Visual Studio tools from the command line. I could have the name of the batch
file slightly wrong, but it was something like that.

2. I'm running Visual Studio 2005 on my PC and it builds the Ghostscript 8.64
release correctly. In VS 2005 you can open a command prompt properly configured
from Start->Programs->Microsoft Visual Studio 2005->Visual Studio Tools->Visual
Studio 2005 Command Prompt

Comment 13 Ken Sharp 2009-02-04 09:15:19 UTC
Thanks for the correction Ray. THe vsvars32.bat file can be found (on my
installation of VS 2005) in \Program Files\Microsoft Visual Studio 8\Common7\Tools.

I can't find any reference in the help for the quoted error (0xC0000135) I'm afraid.
Comment 14 Harry McKame 2009-02-05 10:19:57 UTC
I've followed all the directions and have successfully created the release using
VS2005, with the result that now both gswin32.exe and gsdll32.dll don't work at all.

I think I'll therefore wait patiently for the binary release for Windows before
deciding if my bug has or has not been corrected in 8.64.

Thank you for all your efforts in trying to get me going.
I remark that I previously did compile 8.63 from the sources without any
problem, and without any need to contact you. However, I am now for some reason
unable to produce a viable 8.64. I suspect that some file(s) are missing, but
will know more when I'll compare my compiled release with the future official
release.
Comment 15 Harry McKame 2009-02-05 10:44:02 UTC
Further news: I've installed the 8.64 binary release.
The result is that all the pdf files I've tried now work in BOTH gswin32.exe and
gsdll32.dll, except that ...
the problematic pdf attached here is the only file I've found that does work in
gswin32.exe, but NOT in gsdll32.dll !
Comment 16 Ken Sharp 2009-02-06 00:57:34 UTC
Hmm, I'm puzzled by what you are saying here. gswin32.exe is not a complete
stand-alone application, it uses the gsdll32 DLL which, contains the actual
interpreter code, to do most of the work.

So I'm a bit puzzled as to how gswin32.exe works but gsdll32.dll doesn't. 

Its also not clear how you are testing the file with gsdll32.dll, since this
isn't an executable. Is this being used from within your own application ? What
do you mean when you say that the file 'doesn't work' with gsdll32.dll, do you
get an error message or something else ?

If you are using the DLL from your own application, are you absolutely certain
you are using the correct DLL ?

Comment 17 Harry McKame 2009-02-06 01:18:59 UTC
gsdll32 is used by my program, and you're quite right to be puzzled - my test
program for this file was in error. I've corrected the error, and my final
conclusion is that the bug reported in 8.63 is definitely resolved in 8.64.
I thank you for your outstanding support.