[XeTeX] Segmentation fault in xdvipdfmx

[Mike Maxwell]

I've been trying to track down a bug in producing a pdf from xelatex. 
It's been frustrating, as with no change to the .xelatex doc, it will 
sometimes fail, and sometimes succeed.  Several times I thought I had 
pinned down the problem in my xelatex code, before I realized that that 
it just wasn't consistent.

The document in question is converted from a DocBook XML to xelatex form 
using dblatex.  But I've been working directly with the xelatex file to 
try to track this down.  It appears to be font-dependent; the PDF gets 
produced OK when I use the Nafees Nastaleeq font, but not when I use the 
Alvi Nastaleeq font.  Unfortunately, there's a problem with the 
placement of a certain diacritic in the Nafees font, so we need it to 
work with the Alvi font.

The funny thing is that a small sample document worked just fine with 
the Alvi font (which is how we know that the diacritic placement is 
better with this font).  In fact, if I cut most of the text out of my 
large doc (leaving in some Urdu text), it will crash the first time I 
run xelatex, but often runs the second time--which is why I say it's not 
consistent. Unfortunately, this means that I can't seem to produce a 
minimal document which consistently demonstrates the problem.

The problem is happening in xdvipdfmx, which segment faults.  We have 
version 0.7.3 from the TexLive2008 release (and XeTeX 
3.1415926-2.2-0.999.6).

Based on a suggestion from an earlier posting in this mailing list 
(http://www.tug.org/pipermail/xetex/2008-January/008163.html), I ran 
xelatex with the -no-pdf option, then ran xdvipdfmx with the -E and -vv 
options, redirecting stderr into a file.  I'll be happy to send someone 
this logfile; I don't want to clutter this list with it, as it's about 
100kb.  The logfile is full of warnings, such as the following; I have 
no idea how serious they are, nor how or whether these relate to the 
segment fault.
----------------
pdf_font>> Input encoding "Identity-H" requires at least 2 bytes.
pdf_font>> The -m <00> option will be assumed for 
"/usr/share/fonts/ttF/CharisSILR.ttf".
(CID:CharisSIL)
...
** WARNING ** Object reference with key "table.2.6" is in use.
...
otf_cmap>> Creating ToUnicode CMap for 
"/usr/share/fonts/ttF/alvi_Nastaleeq_Lahori_shipped.ttf"...
...
** WARNING ** No Unicode mapping for glyph name "iy" found.
No Unicode mapping available: GID=16712, name=iy
----------------

Finally, the msg suggesting running xdvipdfmx in verbose mode suggests 
using xdv2pdf as a work-around.  Unfortunately, that doesn't seem to be 
on our Linux machines; perhaps it's a Mac thing.
-- 
    Mike Maxwell
    What good is a universe without somebody around to look at it?
    --Robert Dicke, Princeton physicist