Bug 241794

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