[XeTeX] xelatex math problem with sqrt

Jonathan Kew jonathan_kew at sil.org
Sat May 31 17:39:29 CEST 2008


On 31 May 2008, at 2:48 pm, Ulrike Fischer wrote:

> Am Thu, 29 May 2008 16:54:45 +0100 schrieb Jonathan Kew:
>
>
>>> I made some tests. As far as I can see the problem disappear when I
>>> set enough trace-options. It doesn't matter what options I set as
>>> long as I set enough. So I think there is a timing problem.
>
>>
>> That's really strange; I can't imagine how timing could be important.
>> Perhaps more likely there's some kind of memory allocation/
>> overwriting issue, and when you start changing trace options you
>> influence how the allocations and access happens.
>>
>> It would be good to somehow figure out what's really going on, as
>> this might indicate a potential bug in any or all implementations; we
>> just happen to "get lucky" on the other platforms so far, and not
>> actually trigger it. Or, of course, it could be something specific to
>> the MikTeX port.
>
> Christian wrote the following in the bug report:
>
> "I can now reproduce the issue and know where it occurs. I am not sure
> whether it is a MiKTeX (or Windows) specific problem: the font_mapping
> array isn't initialized with zeros. After zeroing the array (in the
> init routine), the crash does not occur anymore.
>
> The fix will be made available with the next update. Please reopen  
> this
> report, if it does not solve your problem."

It shouldn't be necessary to initialize the font_mapping array with  
zeros, because whenever a font is loaded, the corresponding entry in  
font_mapping should be specifically set to the newly-loaded mapping  
pointer, or to NULL if no mapping was specified.

This happens in a couple of ways, depending on the kind of font: for  
"native" fonts loaded via find_native_font, the mapping is returned  
to the WEB code in a global variable, which is initialized to NULL in  
findnativefont() in XeTeX.c. And for TFM fonts, the function  
loadtfmfontmapping() should return either a valid mapping pointer, or  
NULL.

I'll re-examine the possible code paths to see if there's a  
possibility of the value being left uninitialized; alternatively, are  
there changes in MiKTeX that mean the initialization to NULL gets  
missed in some case?

JK



More information about the XeTeX mailing list