When compiling dirac-0.10.0 with USE=doc, the build process freezes while building documentation. I'm classifying this as major, since instead of dying, the emerge simply stops. # USE=doc emerge dirac [...] make[4]: Entering directory `/var/tmp/portage/media-video/dirac-0.10.0/work/dirac-0.10.0/doc/documentation/code/api' SOURCEDIR="." \ HAVEDOT="true" \ doxygen ./dirac_api.doxygen Warning: Tag `MAX_DOT_GRAPH_WIDTH' at line 834 of file ./dirac_api.doxygen has become obsolete. To avoid this warning please update your configuration file using "doxygen -u" [...] Generating code for file transform_byteio.h... Generating code for file upconvert.h... Generating code for file video_format_defaults.h... Generating code for file wavelet_utils.h... Generating file documentation... Generating docs for file accessunit_byteio.h... (process:19031): Pango-WARNING **: Error loading GPOS table 5503 And then nothing happens - the build process freezes. When emerging with USE=-doc, the emerge process completes correctly. I have tried both doxygen-1.5.5 and doxygen-1.5.6, with the same result. If it matters, I am using graphviz-2.20.2 # emerge --info Portage 2.2_rc8 (default/linux/x86/2008.0/desktop, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.26-gentoo-r1 i686) ================================================================= System uname: Linux-2.6.26-gentoo-r1-i686-Intel-R-_Pentium-R-_M_processor_1.60GHz-with-glibc2.0 Timestamp of tree: Sun, 17 Aug 2008 23:36:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6-r1 dev-lang/python: 2.4.4-r14, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/confcache: 0.4.2-r1 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.5 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13, 2.62-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.16.1-r3, 2.17-r2, 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.4 virtual/os-headers: 2.6.25-r4 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium-m -O2 -pipe -frename-registers" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=pentium-m -O2 -pipe -frename-registers" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks parallel-fetch preserve-libs sandbox sfperms strict unmerge-orphans userfetch userpriv" GENTOO_MIRRORS="http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US.utf8" LDFLAGS="-Wl,--as-needed -Wl,-O1" LINGUAS="C en POSIX ru" MAKEOPTS="-j2"
Created attachment 163167 [details] dirac-0.10.0 build log with USE=doc
Does this happen only when you don't have access to the Internet?
(In reply to comment #2) > Does this happen only when you don't have access to the Internet? I tested it, and documentation build process freezes both when I'm connected and when I am disconnected. (By the way, why would you think that the presence of network connection would affect doxygen?) I've also tried to recompile pango, graphviz and doxygen. Didn't help.
It seems to be a font problem, according to: http://osdir.com/ml/gnome.gtk+.internationalization/2005-08/msg00024.html Does running 'fc-cache -v -f' help? and what's its output? See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483791 Do you have freefont-ttf installed ? if I install them, generating dirac docs will produce similar warnings (though it doesn't seem to hang here). What pango/doxygen/graphviz version are you using ?
(In reply to comment #4) > Does running 'fc-cache -v -f' help? and what's its output? Doesn't help. # fc-cache -v -f /usr/share/fonts: caching, new cache contents: 0 fonts, 32 dirs /usr/share/fonts/100dpi: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/75dpi: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/CID: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/Speedo: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/TTF: caching, new cache contents: 12 fonts, 0 dirs /usr/share/fonts/Type1: caching, new cache contents: 28 fonts, 0 dirs /usr/share/fonts/afms: caching, new cache contents: 0 fonts, 1 dirs /usr/share/fonts/afms/adobe: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/arabeyes-fonts: caching, new cache contents: 39 fonts, 0 dirs /usr/share/fonts/arphicfonts: caching, new cache contents: 12 fonts, 0 dirs /usr/share/fonts/baekmuk-fonts: caching, new cache contents: 4 fonts, 0 dirs /usr/share/fonts/corefonts: caching, new cache contents: 30 fonts, 0 dirs /usr/share/fonts/cyrillic: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/default: caching, new cache contents: 0 fonts, 1 dirs /usr/share/fonts/default/ghostscript: caching, new cache contents: 35 fonts, 0 dirs /usr/share/fonts/dejavu: caching, new cache contents: 21 fonts, 0 dirs /usr/share/fonts/droid: caching, new cache contents: 8 fonts, 0 dirs /usr/share/fonts/encodings: caching, new cache contents: 0 fonts, 1 dirs /usr/share/fonts/encodings/large: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/freefonts: caching, new cache contents: 78 fonts, 0 dirs /usr/share/fonts/indic: caching, new cache contents: 9 fonts, 0 dirs /usr/share/fonts/kochi-substitute: caching, new cache contents: 2 fonts, 0 dirs /usr/share/fonts/liberation-fonts-ttf: caching, new cache contents: 12 fonts, 0 dirs /usr/share/fonts/local: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/mathematica-fonts: caching, new cache contents: 82 fonts, 0 dirs /usr/share/fonts/misc: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/proggy-fonts: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/sazanami: caching, new cache contents: 2 fonts, 0 dirs /usr/share/fonts/sharefonts: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/terminus: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/texcm-ttf: caching, new cache contents: 4 fonts, 0 dirs /usr/share/fonts/ttf-bitstream-vera: caching, new cache contents: 10 fonts, 0 dirs /usr/share/fonts/ttf-gentium: caching, new cache contents: 4 fonts, 0 dirs /usr/share/fonts/util: caching, new cache contents: 0 fonts, 0 dirs /usr/share/fonts/webby-fonts: caching, new cache contents: 0 fonts, 0 dirs /usr/local/share/fonts: caching, new cache contents: 0 fonts, 2 dirs /usr/local/share/fonts/liberation-fonts: caching, new cache contents: 12 fonts, 0 dirs /usr/local/share/fonts/vista-fonts: caching, new cache contents: 25 fonts, 0 dirs /root/.fonts: skipping, no such directory /var/cache/fontconfig: cleaning cache directory /root/.fontconfig: not cleaning non-existent cache directory fc-cache: succeeded > Do you have freefont-ttf installed ? if I install them, generating dirac docs > will produce similar warnings (though it doesn't seem to hang here). I had freefont-ttf installed. After unmerging it, the GPOS table warning is gone, but the build process still freezes after "Generating docs for file accessunit_byteio.h..." So this is not freefont's fault. > What pango/doxygen/graphviz version are you using ? pango-1.20.5 (USE="X doc -debug") doxygen-1.5.6 (USE="latex qt3 -debug -doc -elibc_FreeBSD -nodot") (note: I tried doxygen-1.5.5, and it also freezes) graphviz-2.20.2 (USE="cairo cgraph doc gnome gtk java jpeg nls perl png python ruby tcl -examples")
Created attachment 163217 [details] a00305.dot After looking at the process tree, the process that hangs and causes doxygen to freeze is dot a00305.dot -Tpng -o a00305.png I'm attaching doc/documentation/code/api/html/a00305.dot in case it's useful. When I try to run "dot a00305.dot -Tpng -o a00305.png" in the terminal, it freezes segfaults 4/5 times and freezes 1/5 times. (However, when it gets run from make doc in dirac-0.10.0 it always freezes.) This is the output from running "dot -v a00305.dot -Tpng -o a00305.png" in the terminal: Activated plugin library: libgvplugin_pango.so.5 Using textlayout: textlayout:cairo Activated plugin library: libgvplugin_dot_layout.so.5 Using layout: dot:dot_layout Using render: cairo:cairo Using device: png:cairo:cairo The plugin configuration file: /usr/lib/graphviz/config was successfully loaded. render : cairo dot fig gd map ps svg tk vml vrml xdot layout : circo dot fdp neato nop nop1 nop2 twopi textlayout : textlayout device : canon cmap cmapx cmapx_np dia dot eps fig gd gd2 gif gtk hpgl imap imap_np ismap jpe jpeg jpg mif mp pcl pdf pic plain plain-ext png ps ps2 svg svgz tk vml vmlz vrml vtx wbmp xdot xlib loadimage : (lib) gd gd2 gif jpe jpeg jpg png ps svg xbm fontname: "FreeSans" resolved to: "DejaVu Sans 9.9990234375" network simplex: 27 nodes 34 edges 1 iter 0.00 sec mincross: pass 0 iter 0 trying 0 cur_cross 8 best_cross 8 mincross: pass 0 iter 1 trying 0 cur_cross 4 best_cross 4 mincross: pass 0 iter 2 trying 0 cur_cross 3 best_cross 3 mincross: pass 0 iter 3 trying 1 cur_cross 3 best_cross 3 mincross: pass 1 iter 0 trying 0 cur_cross 3 best_cross 3 mincross: pass 1 iter 1 trying 1 cur_cross 7 best_cross 3 mincross: pass 1 iter 2 trying 2 cur_cross 4 best_cross 3 mincross: pass 1 iter 3 trying 3 cur_cross 3 best_cross 3 mincross: pass 2 iter 0 trying 0 cur_cross 3 best_cross 3 mincross: pass 2 iter 1 trying 1 cur_cross 4 best_cross 3 mincross: pass 2 iter 2 trying 2 cur_cross 3 best_cross 3 mincross: pass 2 iter 3 trying 3 cur_cross 3 best_cross 3 mincross: pass 2 iter 4 trying 4 cur_cross 3 best_cross 3 mincross: pass 2 iter 5 trying 5 cur_cross 4 best_cross 3 mincross: pass 2 iter 6 trying 6 cur_cross 3 best_cross 3 mincross: pass 2 iter 7 trying 7 cur_cross 3 best_cross 3 mincross: pass 2 iter 8 trying 8 cur_cross 3 best_cross 3 mincross G: 3 crossings, 0.00 secs. network simplex: 69 nodes 100 edges 13 iter 0.00 sec routesplines: 34 edges, 110 boxes 0.00 sec Using render: cairo:cairo Using device: png:cairo:cairo dot: allocating a 3050K cairo image surface and then the process freezes. When I break by pressing Ctrl-C, the following output appears: ^CUsing render: cairo:cairo Using device: png:cairo:cairo Segmentation fault
> When I try to run "dot a00305.dot -Tpng -o a00305.png" in the terminal, it > freezes segfaults 4/5 times and freezes 1/5 times. I meant it freezes 80% of the time and simply segfaults 20% of the time.
Sounds like a graphviz bug then; i get some doxygen errors running dot too, but here it seems to always segfault. Can you try if downgrading graphviz helps ?
(In reply to comment #8) > Can you try if downgrading graphviz helps ? No, I'm getting the same problem with graphviz-2.18
I think I found the culprit. I was using libpng-1.2.30 Downgrading to libpng-1.2.27 fixes the graphviz freeze/segfaults.
Specifically, it's the following commit, introduced between libpng-1.2.29 and libpng-1.2.30: diff -ru libpng-1.2.29-work/pngwrite.c libpng-1.2.30-work/pngwrite.c --- libpng-1.2.29-work/pngwrite.c 2008-05-08 07:58:06.000000000 -0400 +++ libpng-1.2.30-work/pngwrite.c 2008-08-15 10:14:43.000000000 -0400 @@ -393,6 +393,13 @@ /* write end of PNG file */ png_write_IEND(png_ptr); + /* This flush, added in libpng-1.0.8, removed from libpng-1.0.9beta03, + * and restored again in libpng-1.2.30, may cause some applications that + * do not set png_ptr->output_flush_fn to crash. If your application + * experiences this problem, please report the event to + * png-mng-implement at lists.sf.net . + */ + png_flush(png_ptr); } #if defined(PNG_WRITE_tIME_SUPPORTED)
I'll make this one block the libpng-1.2.30 bug then, and CC base-system.
Could you try to reproduce this bug with libpng-1.2.31_rc01 which was just added to the tree?
(In reply to comment #13) > Could you try to reproduce this bug with libpng-1.2.31_rc01 which was just > added to the tree? libpng-1.2.31_rc01 is still broken. Dot still freezes/segfaults.
I've now figured out why the crash happens. The libpng devs have changed the semantics of png_write_end(), and are unwilling to change them back, because that would lead to other crashes :( http://sourceforge.net/mailarchive/forum.php?thread_name=4ab4bbae0808190908y47c2f133w4fd3630f1e54b0fd%40mail.gmail.com&forum_name=png-mng-implement As a result of this semantic change, the way cairo was calling png_set_write_fn() and png_write_end() has suddenly become invalid. As a result, when you call cairo_surface_write_to_png_stream(), you will probably get a segmentation fault. I've submitted a bug upstream at https://bugs.freedesktop.org/show_bug.cgi?id=17212 - see it for a more in-depth analysis.
Created attachment 163333 [details, diff] cairo-1.6.4-flush-png.patch Patch to cairo to not crash with new versions of libpng. This patch fixes my graphviz-related freezes and segfaults.
Reassigning: Guys, cairo is your child. )
Good work on tracking this down Alex. Sticky situation for us, because if someone upgrades their libpng without rebuilding cairo, they've got some issues. Hopefully we'll push 1.6.6 (once it's out) stable before libpng 1.2.30 or higher. Committed.
