Skip to content
Permalink
master
Go to file
 
 
Cannot retrieve contributors at this time
486 lines (256 sloc) 21 KB
original_url created_at updated_at closed_at status type resolution reporter owner priority milestone component version
2009-11-01 17:54:32 -0800
2015-07-28 01:00:36 -0700
2014-06-01 00:54:35 -0700
closed
usability
Not To Be Fixed
tgl@…
jeremyhu@…
Important
later
xserver
2.4.0 (xserver-1.5.3-apple14)

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

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@… commented on Nov 1, 2009

xscope trace


jeremyhu@… commented on Nov 1, 2009

  • Status changed from new to assigned
  • Version set to 2.4.0 (xserver-1.5)
  • Milestone set to 2.4.1

Did you have this problem with 2.4.0 on Leopard?


tgl@… commented on Nov 7, 2009

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@… commented on Jan 5, 2010

  • Milestone changed from 2.5.0 to 2.5.1

jeremyhu@… commented on Apr 2, 2010

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@… commented on Apr 3, 2010

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@… commented on Apr 3, 2010

(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@… commented on Apr 3, 2010

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@… commented on Apr 3, 2010

tk 8.5.8 (no patches)


tgl@… commented on Apr 4, 2010

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@… commented on Apr 5, 2010

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@… commented on Apr 5, 2010

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


jeremyhu@… commented on Apr 16, 2010

Have you been able to try xscope-ing this?


tgl@… commented on Apr 17, 2010

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@… commented on Apr 22, 2010

Please update to 2.5.1_beta2 which has the fixed xscope.


tgl@… commented on Apr 23, 2010

xscope trace with Powerbook G4 as client


tgl@… commented on Apr 23, 2010

xscope trace with HPPA as client


tgl@… commented on Apr 23, 2010

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@… commented on Apr 23, 2010

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@… commented on Apr 23, 2010

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@… commented on Apr 23, 2010

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


tgl@… commented on Apr 23, 2010

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@… commented on Apr 23, 2010

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@… commented on May 4, 2010

<rdar://problem/7944092>


jeremyhu@… commented on Jun 28, 2010

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@… commented on Jun 28, 2010

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@… commented on Jun 28, 2010

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


jeremyhu@… commented on Jul 1, 2010

  • Milestone changed from 2.5.1 to 2.5.2

jeremyhu@… commented on Jul 20, 2010

  • Summary changed from Bad-value failure on OpenFont request in Snow Leopard servers to Bad-value failure on OpenFont request for some Snow Leopard TTF fonts

jeremyhu@… commented on Nov 23, 2010

  • Milestone changed from 2.6.0 to 2.6.1

Not a new bug, and the problem exists in other X11 servers, so deferring.


jeremyhu@… commented on Feb 28, 2011

  • Milestone changed from 2.6.1 to later

It doesn't look like there's much motion on this upstream... Pushing back until I can get face time with people at XDC.


woods-macosforge.org@… commented on Jun 28, 2013

I've been just reminded of this issue again today.

I can confirm that the problem has been partially fixed somehow on 10.8.4 with Xquartz 2.7.4, but I don't think the fix is part of the Xserver itself.

For me it still rears its ugly head if I try to use any of the Menlo family of fonts in an X application, from, say, xfontsel, xfd, xterm, etc. I see the exact same error from such applications as tlg mentioned in comment16 above.

I realize Menlo may not have a bitmap representation (I don't know for sure if it does or not), so the fact I can't use it may not be too surprising (I only know enough of the current state of font handling in X to be a danger to myself), however xlsfonts and xfontsel still offer it as a possible choice, so at least I think I can play the dumb user here.

However from an application that can use true-type fonts, such as Emacs compiled with Xft it's a bit more complicated. The issue seems to be related to some library (such as libXft, libfreetype, libfontconfig?) that the application is linked with, not with the Xserver (or the font itself?), but also there's some component as to which library it is built with, since updating the dynamic link versions of these libraries doesn't fix the bug.

Below is a bit of a crash report from emacs-23.3 on 10.6.8 running Xquartz 2.7.4. This happens immediately as I try to set "-*-menlo-medium-r-*--14-*-*-*-m-*-iso10646-1" as my frame font.

However with emacs-24, compiled and running on 10.8.4, but displayed on a 10.6.8 system with Xqartz 2.7.4, this choice of font works just fine (and it is a most excellent choice of font for reading and writing code).

Here's where it gets really odd. If I re-compile emacs-23 (from fink, thus with GTK+), thus use the latest Xquartz headers (and libraries), it still fails. However if I build emacs-24.3.50 (git HEAD) on 10.6.8, using only minimal fink libraries (avoiding gtk+), it works with the Menlo font. As far as I can tell there's been no recent change in the emacs font handling code, but I may not know all the right places to work. I may try building emacs-23 on the new machine, with as much of the same config as possible, to see if it works or not, but not today.

Process:         emacs-23.3 [54677]
Path:            /sw/bin/emacs-23.3
Identifier:      emacs-23.3
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  ??? [1]

Date/Time:       2013-06-28 13:21:42.064 -0700
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6

Interval Since Last Report:          647461 sec
Crashes Since Last Report:           4
Per-App Crashes Since Last Report:   2
Anonymous UUID:                      33B9CD73-FFF1-4FD6-980B-DA59881CFB48

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
abort() called

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib               0x00007fff8877e0b6 __kill + 10
1   libSystem.B.dylib               0x00007fff8881e9f6 abort + 83
2   emacs                           0x000000010012a0be internal_condition_case + 49
3   emacs                           0x00000001000f514f Fdo_auto_save + 1223
4   emacs                           0x00000001000c0046 shut_down_emacs + 183
5   emacs                           0x00000001000c07c9 fatal_error_signal + 250
6   libSystem.B.dylib               0x00007fff887901ba _sigtramp + 26
7   libSystem.B.dylib               0x00007fff8877e0b6 __kill + 10
8   libSystem.B.dylib               0x00007fff8881e9f6 abort + 83
9   emacs                           0x000000010012a0be internal_condition_case + 49
10  emacs                           0x00000001000f514f Fdo_auto_save + 1223
11  emacs                           0x00000001000c0046 shut_down_emacs + 183
12  emacs                           0x000000010008e640 x_connection_closed + 437
13  emacs                           0x000000010008eaa2 x_error_quitter + 134
14  emacs                           0x000000010008eaeb x_error_handler + 37
15  libX11.6.dylib                  0x0000000101045c40 _XError + 374
16  libX11.6.dylib                  0x0000000101047a4c _XReply + 1025
17  libX11.6.dylib                  0x0000000101041754 XSync + 116
18  emacs                           0x0000000100087b17 x_catch_errors + 47
19  emacs                           0x000000010008e51a x_connection_closed + 143
20  emacs                           0x000000010008eaa2 x_error_quitter + 134
21  emacs                           0x000000010008eaeb x_error_handler + 37
22  libX11.6.dylib                  0x0000000101045c40 _XError + 374
23  libX11.6.dylib                  0x0000000101047a4c _XReply + 1025
24  libX11.6.dylib                  0x00000001010292b4 _XQueryFont + 205
25  libX11.6.dylib                  0x0000000101029d7a XLoadQueryFont + 352
26  emacs                           0x000000010017fbb0 xfont_match + 302

....


tgl@… commented on Aug 5, 2013

I just found that this issue is still there in xquartz 2.7.5_rc2:

$ wish
% font actual [list zapfdingbats 12 roman normal] -family
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:  0x1000005
  Serial number of failed request:  234
  Current serial number in output stream:  235

In this case the client machine is an x86_64 Linux box, not my old HPPA box, so the theory that bigendian client might have something to do with it is destroyed, just in case you thought that might still be relevant. Worth noting though is that this isn't an exactly standard build of tk: it's 8.5.13 with --disable-xft. I can't reproduce the behavior with a tk build I have on my Mac that has Xft linked in. So evidently the Xft code paths dodge this problem.

I'm continuing to work around the problem with the hack you suggested in 2010 of removing use of certain font directories, so it's not urgent. I'd just been experimenting to see if I could remove that hack yet ... seems not.


jeremyhu@… commented on Jun 1, 2014

  • Status changed from assigned to closed
  • Resolution set to Not To Be Fixed

This is not something specific to XQuartz, so I suggest you file a bug report at http://bugs.freedesktop.org (feel free to reference the upstream report here). Sorry I can't be of more help, but that's likely the quickest path to success. The xorg-devel mailing list will likely be of help as well.

You can’t perform that action at this time.