[XeTeX] Segmentation fault

[Malcolm Ross]

Bruno,

By way of further report, I've installed, one after the other, 0.93, 
0.92 and 0.91, but all give a segmentation fault at exactly the same 
point.

Looking at your quote from Jonathan Kew below, I see that the 
segmentation fault in 0.92 was triggered by a particular piece of code. 
In the present instance, the segmentation fault occurs after all the 
packages (listed in a separate .sty file) are loaded, and (I think) 
before any code in the .tex file itself is processed. Significant facts 
are that I have changed nothing in the .sty file recently, and that the 
segmentation fault occurs regardless of which of my numerous XeTeX .tex 
files I run through XeTeX. This makes me think there is no code 
trigger.

Incidentally, I had already run DiskUtility to make it check disk 
permissions, as Peter suggested. No change.

Malcolm



On 26/07/2005, at 12:45 PM, Bruno Voisin wrote:

> Le 26 juil. 05 à 12:01, Malcolm Ross a écrit :
>
>> I am taking the liberty of sending this direct to you, not to the 
>> list, as there is an attachment. Many thanks for your helpful 
>> message. I have done what you suggested, and the Console crash 
>> messages and the XeTeX crash log are in the attached file. I have 
>> looked at them, but I have little idea what they mean. Any advice 
>> would be greatly appreciated.
>>
>> Is it possible hat I have a hardware fault?
>
> I am cc'ing this to the XeTeX list, since the problem looks like a 
> XeTeX bug.
>
> This extract from your xelatex.crash.log:
>
>> Exception:  EXC_BAD_ACCESS (0x0001)
>> Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x0890c000
>>
>> Thread 0 Crashed:
>> 0   ATS              0x96c1aa0c FixPostScriptName + 0x128
>> 1   ATS              0x96c19598 FOGetNameInternal + 0x2a4
>> 2   ATS              0x96c0ae70 _eFOGetName + 0x288
>> 3   ATS              0x96c0abc4 FOGetName + 0x60
>> 4   com.apple.QD     0x915b7c64 ATSUGetIndFontName + 0xa0
>> 5   xelatex          0x000567d8 init_font_dicts() + 0x1a0 
>> (xetexmac.c:1670)
>> 6   xelatex          0x00057060 find_font_by_name + 0x3c 
>> (xetexmac.c:1670)
>> 7   xelatex          0x00054484 findatsufont + 0x11c (xetexmac.c:836)
>> 8   xelatex          0x0002baa8 zloadnativefont + 0x8c (xetex1.c:3162)
>> 9   xelatex          0x0002c290 zreadfontinfo + 0x84 (xetex1.c:3334)
>> 10  xelatex          0x00049b60 znewfont + 0x414 (xetex2.c:5922)
>> 11  xelatex          0x00009444 prefixedcommand + 0x15bc 
>> (xetexini.c:2821)
>> 12  xelatex          0x0004d704 maincontrol + 0xbf0 (xetex2.c:7731)
>> 13  xelatex          0x00011510 mainbody + 0x246c (xetexini.c:4870)
>> 14  xelatex          0x000501d8 main + 0x14 (xetexextra.c:384)
>> 15  xelatex          0x00002440 _start + 0x188 (crt.c:267)
>> 16  dyld             0x8fe1a558 _dyld_start + 0x64
>
> looks suspiciously like one reported earlier on 9 March in a thread 
> "XeTeX .92: *** unexpected DVI command: -1 Segmentation fault":
>
>>> Exception:  EXC_BAD_ACCESS (0x0001)
>>> Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x83c4740c
>>>
>>> Thread 0 Crashed:
>>> 0   xelatex     0x0003010c hlistout + 0x26c (xetex1.c:5057)
>>> 1   xelatex     0x0003140c hlistout + 0x156c (xetex1.c:5459)
>>> 2   xelatex     0x0003140c hlistout + 0x156c (xetex1.c:5459)
>>> 3   xelatex     0x000327bc vlistout + 0x2dc (xetex1.c:5997)
>>> 4   xelatex     0x000327b4 vlistout + 0x2d4 (xetex1.c:5995)
>>> 5   xelatex     0x000327b4 vlistout + 0x2d4 (xetex1.c:5995)
>>> 6   xelatex     0x00033580 zshipout + 0x754 (xetex1.c:6348)
>>> 7   xelatex     0x0004d024 maincontrol + 0x714 (xetex2.c:7365)
>>> 8   xelatex     0x00011314 mainbody + 0x246c (xetexini.c:4870)
>>> 9   xelatex     0x0004ffd4 main + 0x14 (xetexextra.c:384)
>>> 10  xelatex     0x00002244 _start + 0x188 (crt.c:267)
>>> 11  dyld        0x8fe1a558 _dyld_start + 0x64
>
> Here's what Jonathan Kew (the XeTeX developer) had said at the time:
>
>> You've found a nice shiny new bug of your very own here, freshly 
>> minted for release 0.92. :-) Reverting to 0.91 avoids the issue, so 
>> if you like you could grab that installer off the "version history" 
>> page and use it for now. But I'll aim to produce 0.93, including a 
>> fix for this, once I get back to the office tomorrow.
>>
>> The fragment that actually triggers the crash is "\text{ or }", which 
>> you have in a couple of your displayed equations. To be exact, it's 
>> the trailing space here that causes the problem. If you replace 
>> "\text{ or }" with "\text{ or~}" (i.e., make that a non-breaking 
>> "tie" space)--and any other similar cases--it won't crash.
>>
>> All this is a result of my attempt to fix the version 0.9 problem 
>> with right-to-left AAT fonts, reported by Otared Kavian; that 
>> involved restructuring the AAT layout code, and clearly I got it 
>> slightly wrong. My apologies!
>
> Your Word problem seems completely unrelated. Apparently you're using 
> a test version of the add-on OCSmart Hacks, which has reached its time 
> limit and needs to be registered.
>
> Hope this helps,
>
> Bruno
>