Bad-value failure on OpenFont request for some Snow Leopard TTF fonts

[tgl@…]

Attached is an xscope trace of the following session:

$ /opt/tcl8.5/bin/wish

% font actual [list zapfdingbats 12 roman normal] -family

run from an HPUX client machine. It fails at the very end with a "bad value" response to an OpenFont request. As far as I can see the requested font number 0xC00005 is within the resource range specified by the server in the startup response, so it should not fail.

I get this type of behavior in both the X server released with Snow Leopard, and xquartz 2.4.1_alpha3. I have never seen it in previous Apple X servers, and the client-side software didn't change when I went to Snow Leopard. Not all OpenFont requests fail --- in fact, it seems that only a few specific fonts may be affected, but I'm not certain about the triggering conditions. The example given here is 100% reproducible though.

I suspect that the fact that HPPA is a big-endian architecture might have something to do with it, since I'm unable to reproduce the problem when running tcl from a little-endian client. Maybe something is forgetting a byte-swap operation somewhere?

[tgl@…]

xscope trace

[jeremyhu@…]

Did you have this problem with 2.4.0 on Leopard?

[tgl@…]

Replying to jeremyhu@…:

Did you have this problem with 2.4.0 on Leopard?

[ sorry for slow response ... if Trac sent me mail about this, I missed it ]

I did not see the problem on Leopard, so far as I can recall. But I am not sure that I spent much time with 2.4.0. I was using 2.3.3.2 for day-to-day use. I see that I had downloaded 2.4.0_rc2, but I think that I had gone back to 2.3.3.2 because of some other issue (possibly the missing-border bug, which I found quite annoying). I could boot into Leopard and try it if you want --- which Xquartz version should I try exactly?

FWIW, I do still see the problem with 2.4.1_beta1, even when adding the 1.7.1.901 server.

[jeremyhu@…]

Are you seeing this problem still with 2.5.0?

If so, please tell me what is returned by this on the remote system and on the local system:

xlsfonts | grep dingbats

When I run your snippet on my remote linux box, it works:

~ $ wish
% font actual [list zapfdingbats 12 roman normal] -family
DejaVu Sans

[tgl@…]

Yup, still fails on 2.5.0.

The xlsfonts test gives

$ xlsfonts | grep dingbats
-misc-zapf dingbats-medium-r-normal--0-0-0-0-p-0-iso10646-1
$ 

Same result from either the HPUX box or locally on my Mac.

I get "DejaVu Sans" also when I try the example from an Intel Linux box. As I said, I think that the problem is probably related to the client machine being big-endian. If that's correct, it could be reproduced on all-Apple hardware if you can scare up a copy of X11-based Tk running on a PPC Mac.

[jeremyhu@…]

(11:29:00 Sat Apr 03 2010 jeremy@yuffie Power Macintosh)
~  $ /opt/local/bin/wish8.5 
% font actual [list zapfdingbats 12 roman normal] -family 
Zapf Dingbats
% ^D
(11:31:01 Sat Apr 03 2010 jeremy@yuffie Power Macintosh)
~  $ uname -a
Darwin yuffie.apple.com 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh

(11:31:03 Sat Apr 03 2010 jeremy@yuffie Power Macintosh)
~  $ echo $DISPLAY
localhost:11.0

It works fine on my remote g5 to my local x86_64.

I'll try my linux/g4 on Monday (it's turned off in my office)

[tgl@…]

Replying to jeremyhu@…:

It works fine on my remote g5 to my local x86_64.

Huh. What tcl/tk version is that exactly (8.5.what?)

The other obvious possibility is that there's a bug in my HPUX machine's (ancient) X libraries; but if that were the case I'd expect to see something demonstrably wrong with the client's messages in the xscope trace, and I didn't see anything. Maybe it'd be worth xscoping your test with the remote g5 and comparing it to mine.

[jeremyhu@…]

tk 8.5.8 (no patches)

[tgl@…]

I updated my HPUX machine to tcl/tk 8.5.8. Still fails. I also installed 8.5.8 from source on my old PowerBook G4 ... and that works fine. So that seems to kill the endianness theory, or at least show that endianness is not the only triggering factor required.

At this point I'm thinking that the most likely explanation is a bug in the HPUX machine's Xlib. However, I still don't see how that would not manifest as an xscope-observable error in the message stream. It seems possible that that old Xlib generates a different (but legal) series of messages for tcl's queries than recent Xlibs do, in which case maybe this is a server-side problem after all.

I tried to repeat the xscope tracing but failed; 2.5.0's xscope seems wedged. I will look into this again when there's an xquartz update with working xscope.

[jeremyhu@…]

You can build xscope yourself. after running ./configure, edit the Makefile and delete the '-DUSE_XTRANS', then run make. That should give you a usable xscope.

[jeremyhu@…]

Here is an updated xscope that you can build with '--disable-xtrans'  http://cgit.freedesktop.org/xorg/app/xscope/commit/?id=344db0911e1e2447abe210b5684269a2a0daf04c

[jeremyhu@…]

Have you been able to try xscope-ing this?

[tgl@…]

I'm not eager to try building my own xscope, so I'm going to wait for an update with working xscope --- is it fixed in 2.5.1_beta1?

[jeremyhu@…]

Please update to 2.5.1_beta2 which has the fixed xscope.

[tgl@…]

xscope trace with Powerbook G4 as client

[tgl@…]

xscope trace with HPPA as client

[tgl@…]

OK, I've uploaded two new xscope traces. In both cases the client-side code is tcl/tk 8.5.8 built from source, and the server is 2.5.1_beta2. There is a nontrivial difference in the sequence of client requests, which I take to be due to using significantly different versions of Xlib. I had previously found that the failure occurs while tk is calling XLoadQueryFont(). I assume that it's still doing that on the G4 client but the internal Xlib implementation is different and doesn't make the same OpenFont call. Anyway it's still true that there is nothing obviously wrong with the OpenFont request that the server is rejecting.

[tgl@…]

Oh, hey, look at this:

pro:~ tgl$ xfd -fn "-misc-zapf dingbats-medium-r-normal--16-*-*-*-*-*-iso10646-1"
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  45 (X_OpenFont)
  Value in failed request:  0x1200014
  Serial number of failed request:  41
  Current serial number in output stream:  42
pro:~ tgl$ 

This is totally local on my Mac, using 2.5.0. Can you reproduce that? If so, I'd guess it's triggered by the old Xlib generating that particular font name where newer ones generate something different from the same Tk request.

[jeremyhu@…]

Yes. odd.

~ $ xlsfonts | grep dingbats
-misc-zapf dingbats-medium-r-normal--0-0-0-0-p-0-iso10646-1

~ $ xfd -fn "-misc-zapf dingbats-medium-r-normal--0-0-0-0-p-0-iso10646-1"
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  45 (X_OpenFont)
  Value in failed request:  0x600014
  Serial number of failed request:  37
  Current serial number in output stream:  38

[jeremyhu@…]

I wonder if the font itself is bad... atleast now I have a reproduction point.

[tgl@…]

Hmm, I can't find such a font at all under /opt/X11/share/fonts/. Is the X server trying to translate on the fly from Apple fonts under /System/Library/Fonts/? If so, it's looking like there's a generic problem with that. In a quick sampling, I get BadValue failures from

xfd -fn "-linotype-helvetica neue-medium-r-normal--0-0-0-0-p-0-iso10646-1"
xfd -fn "-b&h-lucida grande-medium-r-normal--0-0-0-0-p-0-iso10646-1"
xfd -fn "-misc-symbol-medium-r-normal--0-0-0-0-p-0-iso10646-1"
xfd -fn "-misc-thonburi-bold-r-normal--0-0-0-0-p-0-adobe-standard"

though this one works, so apparently they are not *all* bad:

xfd -fn "-bitstream-menlo-medium-r-normal--0-0-0-0-m-0-iso8859-1"

[jeremyhu@…]

Yeah, the font file it should be using is /System/Library/Fonts/ZapfDingbats.ttf

fonts.dir:ZapfDingbats.ttf -misc-zapf dingbats-medium-r-normal--0-0-0-0-p-0-iso10646-1

[jeremyhu@…]

< rdar://problem/7944092>

[jeremyhu@…]

I just verified that this issue is not a regression. It occurs as far back as the OSX Tiger server. Tiger and Leopard did not ship with this font which is why you're seeing the problem now in SnowLeopard, but if you install the font on Tiger, the issue occurs there.

[jeremyhu@…]

It happens on Ubuntu as well... the issue seems to be either a bad font of an issue in X11 outside of XQuartz.app

[jeremyhu@…]

 https://bugs.freedesktop.org/show_bug.cgi?id=28803