Bug 241794 - doxygen gives gs invalid eps so that it fails with "ERROR: /syntaxerror in -file-"
doxygen gives gs invalid eps so that it fails with "ERROR: /syntaxerror in -f...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: tetex (Show other bugs)
8
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jindrich Novy
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-30 14:09 EDT by Mads Kiilerich
Modified: 2013-07-02 19:21 EDT (History)
3 users (show)

See Also:
Fixed In Version: Fedora 9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-27 18:11:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
inline_dotgraph_1.eps created by doxygen (5.68 KB, image/x-eps)
2007-11-30 06:56 EST, Mads Kiilerich
no flags Details
Patch to update epstopdf to newer, working version (3.44 KB, patch)
2007-11-30 08:09 EST, Jindrich Novy
no flags Details | Diff

  None (edit)
Description Mads Kiilerich 2007-05-30 14:09:33 EDT
Description of problem:
doxygen causes gs to fail with "ERROR: /syntaxerror in -file-", apparently
because invalid ps is created

Version-Release number of selected component (if applicable):
doxygen-1.5.2-1.fc7

How reproducible:
consistently when running doxygen on proprietary source code

Steps to Reproduce:
-
  
Actual results:
ERROR: /syntaxerror in -file-
Operand stack:

Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   1   3   %oparray_pop   1   3  
%oparray_pop   1   3   %oparray_pop   1   3   %oparray_pop   .runexec2  
--nostringval--   --nostringval--   --nostringval--   2   %stopped_push
Dictionary stack:
   --dict:1120/1686(ro)(G)--   --dict:0/20(G)--   --dict:102/200(L)--
Current allocation mode is local
Last OS error: 2
ESP Ghostscript 815.04: Unrecoverable error, exit code 1


Expected results:
a pdf ;-)

Additional info:
replacing /usr/bin/dot and /usr/bin/gs with a wrapper reveals that doxygen first
executes
/usr/bin/dot inline_dotgraph_1.dot -Tps -o inline_dotgraph_1.eps
(which warns as mentioned in Bug 241790)
and then doxygen mangles the eps and pipes it to
gs -q -sDEVICE=pdfwrite -dAutoRotatePages=/None
-sOutputFile=inline_dotgraph_1.pdf - -c quit

The mangling changes the following, making the eps input to gs syntactically
invalid:

--- inline_dotgraph_1.eps	2007-05-30 19:57:35.000000000 +0200
+++ /tmp/8378.log	2007-05-30 19:56:01.000000000 +0200
@@ -3,82 +3,15 @@
 %%For: (mk) Mads Kiilerich
 %%Title: something
 %%Pages: (atend)
+%%BoundingBox: 0 0 384 44
+<< /PageSize [384 44] >> setpagedevice
+gsave -114 -374 translate
+%!PS-Adobe-2.0
+%%Creator: Graphviz version 2.12 (Sat May  5 17:55:38 UTC 2007)
+%%For: (mk) Mads Kiilerich
+%%Title: something
+%%Pages: (atend)
 %%BoundingBox: (atend)
-%%EndComments
-save
-%%BeginProlog
-/DotDict 200 dict def
-DotDict begin
-
-/setupLatin1 {
-mark
-/EncodingVector 256 array def
- EncodingVector 0
-
-ISOLatin1Encoding 0 255 getinterval putinterval
-EncodingVector 45 /hyphen put
-
-% Set up ISO Latin 1 character encoding
-/starnetISO {
-        dup dup findfont dup length dict begin
-        { 1 index /FID ne { def }{ pop pop } ifelse
-        } forall
-        /Encoding EncodingVector def
-        currentdict end definefont
-} def
-/Times-Roman starnetISO def
-/Times-Italic starnetISO def
-/Times-Bold starnetISO def
-/Times-BoldItalic starnetISO def
-/Helvetica starnetISO def
-/Helvetica-Oblique starnetISO def
-/Helvetica-Bold starnetISO def
-/Helvetica-BoldOblique starnetISO def
-/Courier starnetISO def
-/Courier-Oblique starnetISO def
-/Courier-Bold starnetISO def
-/Courier-BoldOblique starnetISO def
-cleartomark
-} bind def
-
-%%BeginResource: procset graphviz 0 0
-/coord-font-family /Times-Roman def
-/default-font-family /Times-Roman def
-/coordfont coord-font-family findfont 8 scalefont def
-
-/InvScaleFactor 1.0 def
-/set_scale {
-       dup 1 exch div /InvScaleFactor exch def
-       scale
-} bind def
-
-% styles
-/solid { [] 0 setdash } bind def
-/dashed { [9 InvScaleFactor mul dup ] 0 setdash } bind def
-/dotted { [1 InvScaleFactor mul 6 InvScaleFactor mul] 0 setdash } bind def
-/invis {/fill {newpath} def /stroke {newpath} def /show {pop newpath} def} bind def
-/bold { 2 setlinewidth } bind def
-/filled { } bind def
-/unfilled { } bind def
-/rounded { } bind def
-/diagonals { } bind def
-
-% hooks for setting color 
-/nodecolor { sethsbcolor } bind def
-/edgecolor { sethsbcolor } bind def
-/graphcolor { sethsbcolor } bind def
-/nopcolor {pop pop pop} bind def
-
-/beginpage {	% i j npages
-	/npages exch def
-	/j exch def
-	/i exch def
-	/str 10 string def
-	npages 1 gt {
-		gsave
-			coordfont setfont
-			0 0 moveto
-			(\() show i str cvs show (,) show j str cvs show (\)) show
 		grestore
 	} if
 } bind def
@@ -303,3 +236,5 @@
 end
 restore
 %%EOF
+
+grestore
Comment 1 Mads Kiilerich 2007-11-23 12:33:26 EST
Problem is still in F8.

What is the status?

Is it "nobody else have reported such a problem, and this guy doesn't even
provide a test case - the problem probably goes away"?

Or "yes, known problem, very hard to solve"?
Comment 2 Mads Kiilerich 2007-11-23 12:58:05 EST
Running doxygen through valgrind I get the following once "long" time before the
reported errors.

==807== Syscall param write(buf) points to uninitialised byte(s)
==807==    at 0x6823C3: __write_nocancel (in /lib/libc-2.7.so)
==807==    by 0x621134: new_do_write (in /lib/libc-2.7.so)
==807==    by 0x62141E: _IO_do_write@@GLIBC_2.1 (in /lib/libc-2.7.so)
==807==    by 0x621D0D: _IO_file_overflow@@GLIBC_2.1 (in /lib/libc-2.7.so)
==807==    by 0x622FD8: _IO_switch_to_get_mode (in /lib/libc-2.7.so)
==807==    by 0x6216F7: _IO_file_seekoff@@GLIBC_2.1 (in /lib/libc-2.7.so)
==807==    by 0x618819: _IO_seekoff_unlocked (in /lib/libc-2.7.so)
==807==    by 0x617554: ftell (in /lib/libc-2.7.so)
==807==    by 0x82FE73D: QDir::rmdir(QString const&, bool) const (qstring.h:652)
==807==    by 0x807BEB5: Entry::addSpecialListItem(char const*, int)
(qcstring.h:293)
==807==    by 0x807CB44: Entry::Entry(Entry const&) (entry.cpp:87)
==807==    by 0x807CB8C: Entry::Entry(Entry const&) (qlist.h:112)
==807==  Address 0x4012016 is not stack'd, malloc'd or (recently) free'd

I assume that it could be the same - or a completely different - problem ... But
both seems to be related to some ftell-ish confusion.
Comment 3 Mads Kiilerich 2007-11-23 14:08:28 EST
Ok, doxygen generates a .dot like the one below and calls dot and epstopdf like
below - and that gives the reported error.

cat > inline_dotgraph_1.dot << EOT
digraph foobar {
  rankdir=RL;
  ranksep=0.5; 
  center=true;
  size="14,8.5";
  edge [minlen=1.5, fontsize=8, fontname="Helvetica" ];
  node [colorscheme=pubu3, fontsize=10, fontname="Helvetica"];
  fontname="Helvetica";
 
  FOO [shape=box, style=filled, fillcolor=3, label="foo"];
  BAR [shape=ellipse, style=filled, fillcolor=1, label="bar"];
  BAZ [shape=box, style=filled, fillcolor=2, label="baz"];
  FOO -> BAR;
  BAR -> BAZ;
}
EOT
/usr/bin/dot inline_dotgraph_1.dot -Tps -o inline_dotgraph_1.eps
/usr/bin/epstopdf inline_dotgraph_1.eps --outfile=inline_dotgraph_1.pdf

Assuming that the generated dot code is valid it seems to be a epstopdf / tetex
bug, right?
Comment 4 Ngo Than 2007-11-30 05:59:10 EST
doxygen only generates RTF/HTML/TEX files bit doesn't generates pdf. It's 
surely a bug in tetex. Mads, thanks for tracking this bug.
Comment 5 Jindrich Novy 2007-11-30 06:36:42 EST
Could you provide a minimaistic test case? Specify where pdflatex is called? I
don't use doxygen.
Comment 6 Mads Kiilerich 2007-11-30 06:51:28 EST
To Than in #4: Fine.

The valgrind reports seems to point at a real problem in doxygen which should be
solved - even though it isn't related to the problems I have.

And debugging cases like this is VERY hard because there (AFAIK) is no way to
log which external programs doxygen calls and with which parameters/files. Some
log options (or better documentation of existing options) would help a lot.

But these comments should perhaps be sent in the upstream direction... ;-)
Comment 7 Mads Kiilerich 2007-11-30 06:56:10 EST
Created attachment 273711 [details]
inline_dotgraph_1.eps created by doxygen

Jindrich: I think the example in #3 is minimalistic. 
The inline_dotgraph_1.eps created by doxygen is attached - but creating it as
described is probably easier.
I assume that epstopdf (also part of tetex) calls pdflatex.
Comment 8 Jindrich Novy 2007-11-30 07:22:14 EST
I see it works perfectly with graphviz-2.14.1-3.fc8 and texlive. I'll try it
again with tetex. Anyway consider to upgrade to texlive:

http://people.redhat.com/jnovy/files/texlive/__README__

since tetex is not developed any more.
Comment 9 Mads Kiilerich 2007-11-30 07:57:38 EST
I would assume that with tetex in F8 then we should try to nail bugs down.

But if it is a WONTFIX then I would be just as happy using texlive.

But when I follow the instructions I get plenty of errors like:
http://people.redhat.com/jnovy/files/texlive/i386/texlive-texmf-errata-dvips-2007-0.10.fc8.noarch.rpm:
[Errno 14] HTTP Error 404: Not Found
Comment 10 Jindrich Novy 2007-11-30 08:03:29 EST
Ok, so the problem was caused by a nasty bug in epstopdf. Just updating it makes
it go away.
Comment 11 Jindrich Novy 2007-11-30 08:09:25 EST
Created attachment 273761 [details]
Patch to update epstopdf to newer, working version
Comment 12 Mads Kiilerich 2007-11-30 08:26:37 EST
Yes, the patch helps. I'm now running a full test, and so far it is far better
than usual.
Thanks, Jindrich!
Comment 13 Jindrich Novy 2007-11-30 08:52:48 EST
Not a problem :) I committed the changes in rawhide for now. I'll push f8 update
as soon as more fixes will be gathered.
Comment 14 Jindrich Novy 2007-11-30 09:24:23 EST
BTW. I regenerated the TeXLive repodata for i386, so that you can upgrade
smoothly now if you want to give it a try.
Comment 15 Mads Kiilerich 2007-12-03 13:40:30 EST
Yes, texlive seems to work too. But for F8 I will just patch epstopdf - that
seems to be the least intrusive solution.
Comment 16 Tim Niemueller 2007-12-13 04:42:50 EST
When can we expect a package with the patch for F-8? Koji only shows builds for
rawhide with the patch.
Comment 17 Jindrich Novy 2007-12-13 06:04:40 EST
The fix is committed to CVS and not yet build. Given that there likely won't be
too many tetex related fixes in a short time, I'll build it and put it to
updates-testing with a plan to push it to stable after some time.
Comment 18 Fedora Update System 2008-02-15 21:06:38 EST
tetex-3.0-44.6.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update tetex'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1674
Comment 19 Mads Kiilerich 2008-05-27 18:11:17 EDT
Confirmed working in Fedora 9

Note You need to log in before you can comment on or make changes to this bug.