Hide Forgot
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
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"?
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.
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?
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.
Could you provide a minimaistic test case? Specify where pdflatex is called? I don't use doxygen.
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... ;-)
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.
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.
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
Ok, so the problem was caused by a nasty bug in epstopdf. Just updating it makes it go away.
Created attachment 273761 [details] Patch to update epstopdf to newer, working version
Yes, the patch helps. I'm now running a full test, and so far it is far better than usual. Thanks, Jindrich!
Not a problem :) I committed the changes in rawhide for now. I'll push f8 update as soon as more fixes will be gathered.
BTW. I regenerated the TeXLive repodata for i386, so that you can upgrade smoothly now if you want to give it a try.
Yes, texlive seems to work too. But for F8 I will just patch epstopdf - that seems to be the least intrusive solution.
When can we expect a package with the patch for F-8? Koji only shows builds for rawhide with the patch.
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.
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
Confirmed working in Fedora 9