[XeTeX] Segmentation fault in xdvipdfmx

[Jonathan Kew]

Hi Mike,

On 30 May 2009, at 16:04, Mike Maxwell wrote:

> 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.

Very strange that it's inconsistent. How frequent are the failures....  
does it crash 90% of the time, or only 10%, or what?

> 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.

To clarify, do you get some successful runs and some crashes even with  
the exact same .xdv file? Any chance of narrowing down the range of  
your document that (sometimes) leads to the crash, perhaps by repeated  
bisection?

>  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)

This is normal...

>
> ...
> ** WARNING ** Object reference with key "table.2.6" is in use.

...but this sounds more worrying; offhand, I don't know what it really  
means.

>
> ...
> 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

This means that attempting to search or extract text from the PDF will  
not work very well, as some of the glyphs can't be mapped back to  
Unicode characters, but aside from that it is harmless (and common,  
depending on the fonts used).

>
> ----------------
>
> 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.

That is indeed a Mac (only) thing.

JK