I'm relatively certain this can't be a unicode-math problem; a segfault indicates a problem further down the chain.

Does it work if you write instead \setmathfont{Asana-Math.otf} ? (I'd be surprised if it did, but you never know.)

Also, if you could report this problem on the XeTeX mailing list I'd be most appreciative. As this is a Debian/Linux problem its impossible for me to debug the problem (I'm on Mac OS X). Many thanks.

Just sent it to the mailing list.

According to the prophecy,

\setmathfont{Asana-Math.otf}

I'll close this here because I don't think I can help further. Thanks.

Same problem here. I had the package working with the Debian version of TL 2009, though it did have other problems. Tried it in a virtual machine with 32 bit linux with TL 2010, and it worked fine. Then tried installing TL 2010 on my regular 64 bit linux, and it segfaults when I use \setmathfont, and only when I use \setmathfont.

It is not plausible to suppose the problem has nothing to do with the package in particular. It may not be exclusively limited to the package, but nevertheless, there's nothing in the package that's triggering it, so I think it would be nice if more investigation were done.

Even if you're using a Mac, you can of course install and use linux inside a virtual machine. Not that we're not grateful for you work, but unless this is fixed, the package will be unusable to a large number of LaTeX users.

But I think I can help diagnose. The problem seems to be associated only with certain UNICODE blocks. For example, if I put in the following set of commands rather than just a single general command, I don't get a segfault unless the last one is uncommented:

%\setmathfont[range=\mathord]{STIXGeneral}


Update. I've been testing this a bit more, and I've isolated exactly which characters create problems. There are just a few.

(In the examples, I use STIXGeneral, but the font isn't important. You get the same results whatever font is used.)

The first character is \Vvert. A segfault will be created when \setmathfont is called with any range that includes it, but not by number. In other words:

\setmathfont{STIXGeneral}

\setmathfont[range=\mathfence]{STIXGeneral}

or

\setmathfont[range=\Vvert]{STIXGeneral}

will all lead to segfaults. But oddly, this is OK:

\setmathfont[range={"2980}]{STIXGeneral}

Calling a wider range by number that includes it is OK too.

The other ones that cause problems are all characters from "1D6C0 which are classified as \mathord. This includes "1D6DB, "1D7FB, "1D715, "1D735, "1D74F, "1D76F, and everything from "1D789 and above. A lot of these are nablas and partials, so I wonder if those package options have something to do with this. For these, the command causes a segfault regardless of the method used to include these characters. In other words, any of the following:

\setmathfont[range=\mathord]{STIXGeneral}

\setmathfont[range=\mbfnabla]{STIXGeneral}

or

\setmathfont[range={"1D6C1}]{STIXGeneral}

will all lead to a segfault.

I'm hoping this might be helpful in isolating the problem. Apologies if I'm overlooking something obvious.

Because every character above "1D6C0 is either classified as \mathalpha or as \mathord, right now, a 64 bit linux user can safely use \setmathfont as so:

\setmathfont[range={"0001-"1D6C0,\mathalpha}]{STIXGeneral}

without major problems (unless of course you need one of those missing characters!) Still, I hope it can be fixed to avoid this workaround.

This is neither a problem with unicode-math nor with Debian Linux. It is a bug of xetex for 64-bit binaries. see

http://tug.org/mailman/htdig/tex-live/2008-November/019016.html

http://tug.org/mailman/htdig/tex-live/2008-November/019017.html