The xdvipdfmx seg. fault when I try to convert any xdv to pdf.
But if a dl the binary provided on Xetex site in rpm format it works great.
Using Texlive 2007 (but I think the problem is related to amd64 because a see reports of xdvipdfmx working with Gentoo+Texlive+32bits)
Portage 2.1.3_rc8 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r4, 2.6.19-gentoo-r4 x86_64)
System uname: 2.6.19-gentoo-r4 x86_64 AMD Turion(tm) 64 Mobile Technology ML-34
Gentoo Base System release 1.12.10
Timestamp of tree: Fri, 13 Jul 2007 00:20:01 +0000
ccache version 2.4 [enabled]
dev-java/java-config: 1.3.7, 2.0.33-r1
sys-devel/autoconf: 2.13, 2.61-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
CFLAGS="-O2 -march=athlon64 -pipe -msse3"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-O2 -march=athlon64 -pipe -msse3"
FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/sci-gentoo /usr/local/overlays/musicbrainz-overlay /usr/local/overlays/xgl-coffee /usr/local/overlays/einit-overlay /usr/local/overlays/initng"
Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Can you attach a backtrace please?
(In reply to comment #1)
> Can you attach a backtrace please?
Sorry. the bt
#0 0x000000000041b674 in do_glyph_array (yLocsPresent=<value optimized out>) at dvi.c:1915
#1 0x000000000041c6ac in dvi_do_page (n=0, paper_width=<value optimized out>, paper_height=<value optimized out>, hmargin=<value optimized out>, vmargin=<value optimized out>) at dvi.c:2175
#2 0x000000000041e6e0 in main (argc=<value optimized out>, argv=<value optimized out>) at dvipdfmx.c:705
I discussion about this seg. fault is running on the xetex ml, I don't look like a upstream problem.
Can you please let me know what version of freetype you are using? There appear to be some incompatible changes to freetype that may be causing the problems. I've been discussing this with the author already.
Also, if you could revert to freetype-2.1.10-r3 and retest that would be very helpful.
Oh, and apologies for the delay in answering. I have infrequent access to the net at the moment.
Changing disable to enable at the line
in the freetype ebuild fixes the problems.
Seems like there is some black magic in the xdvipdfmx code relying upon that.
Created attachment 125254 [details, diff]
Patch to fix access to metrics tables
This patches the dependency on FreeType internals in xdvipdfmx
Created attachment 125256 [details]
Ebuild for 0.4
(In reply to comment #4)
> Can you please let me know what version of freetype you are using? There
> appear to be some incompatible changes to freetype that may be causing the
> problems. I've been discussing this with the author already.
> Also, if you could revert to freetype-2.1.10-r3 and retest that would be very
I'm using 2.3.5 reverting to 2.1.10-r3 solves the problem and using the patch provided too.
Yes, xdvipdfmx-0.4 works with provided ebuild and patch.
Remy's ebuild and patch work nicely for me (thanks!), apart from a minor error which results in a glibc double free when generating PDFs containing certain types of fonts, like this:
*** glibc detected *** /usr/bin/xdvipdfmx: double free or corruption (out): 0x00000000004236e0 ***
======= Backtrace: =========
The error is at src/dvi.c:1904 in the patched sources (corresponds to line 20 of Remy's patch). buffer is declared without an initialiser, but then conditionally allocated (dvi.c:1916), and then unconditionally freed (dvi.c:1971). This causes a double-free when the condition at dvi.c:1906 is false, which apparently happens for some fonts.
The trivial fix is to add an initialiser to the declaration of buffer:
FT_Byte *buffer = NULL;
since free(NULL) is a noop.
I will attach an updated patch.
Created attachment 129925 [details, diff]
Patch to fix access to metrics tables (with buffer initialiser)
Obsoletes the previous patch, with a minor bug fix.
Bugzilla won't let me mark the old one as obsolete? :-(
I hope you'll read this because you're currently marked away :/
I'll need this to have xetex on texlive working fine (plus some virtual/tetex -> virtual/latex-base changes)
the patch I have been using for some time in my overlay is basically what you get by typing
svn diff -r92:93 http://scripts.sil.org/svn-public/xdvipdfmx/TRUNK/
and you can get it here :
plus this needs a version bump to 0.4
If you can't answer, I hope you won't mind if I fix the bug ;)
(In reply to comment #12)
> Hi Joshua,
> I hope you'll read this because you're currently marked away :/
> I'll need this to have xetex on texlive working fine (plus some virtual/tetex
> -> virtual/latex-base changes)
> the patch I have been using for some time in my overlay is basically what you
> get by typing
> svn diff -r92:93 http://scripts.sil.org/svn-public/xdvipdfmx/TRUNK/
> and you can get it here :
> plus this needs a version bump to 0.4
> If you can't answer, I hope you won't mind if I fix the bug ;)
If you can test, then feel free to commit the patch. I'm just getting ready to come back, having finally got a working machine and looking at hopefully having some time, but I'm not protective of my ebuilds. Next step will be to get enough net access to get the tree up and running again. I can only test it on amd64 now, so can't do that much extra testing.
So go for it.
(In reply to comment #13)
> So go for it.
thanks, I've commited it.
could you please ping/mail me once you're back ? I've enabled xetex in texlive, as it was stated on xetex website that it would be maintained there, but as far as I can see we can still fetch the same versions as those in texlive from sil.org and having xetex enabled in texlive triggers some circular deps with some fontconfig deps + use doc, they need a latex compiler to build their docs...
for the time being, I'll try to have something clean and working on my side