Re: Emacs crashes when displaying the Euro character

[Chong Yidong]

Richard Stallman <address@hidden> writes:

>     The X error seems to be coming from the call to XPending.  The X
>     libraries manual does not state that XPending can signal an X error,
>     but maybe this is a documentation flaw in the X manual.  In any case,
>     try this patch; it should eliminate this particular crash.
>
> That patch would not be correct.  What the manual means is probably
> that XPending can't _cause_ an error.  And this error was not caused
> by XPending.  But XPending looks for input from the X server, so it
> notices that a message indicating an error has arrived.  Only the
> functions that check input can detect a pending error.

I think this is related to a bug reported by Stefan some time ago, in
which a buggy font doesn't contain a desired character.

  From: Stefan Monnier
  Subject: Bad Protocol request 77
  Date: Tue, 28 Jun 2005 23:08:18 -0700

  My Emacs is crashing in Gnus when displaying some articles.  I haven't
  been able to get a reliable recipe yet, but basically I get a
  backtrace as shown in the appended session.  The first backtrace is
  with x-synchronize turned off, the second is with x-synchronize turned
  on.

  ...

  #0  x_error_quitter (display=0xbfffddb0, error=0xbfffdce0) at xterm.c:7788
  #1  0x0810175c in x_error_handler (display=0x8714568, error=0xbfffdce0) at 
  xterm.c:7753
  #2  0xb7ddf624 in _XError () from /usr/X11R6/lib/libX11.so.6
  #3  0xb7dddb83 in _XReply () from /usr/X11R6/lib/libX11.so.6
  #4  0xb7dd8db4 in XSync () from /usr/X11R6/lib/libX11.so.6
  #5  0xb7dd8e75 in _XSyncFunction () from /usr/X11R6/lib/libX11.so.6
  #6  0xb7dc99c8 in XDrawImageString16 () from /usr/X11R6/lib/libX11.so.6
  #7  0x080f5d8e in x_draw_glyph_string_foreground (s=0xbfffe3bc) at 
xterm.c:1310
  #8  0x080f8a6d in x_draw_glyph_string (s=0xbfffe3bc) at xterm.c:2644

  From: Jan D
  Subject: Re: Bad Protocol request 77
  Date: Fri, 01 Jul 2005 11:38:45 -0700

  >  It's indeed missing from the font,

  I don't know if Emacs can do much about this. Perhaps we could
  handle the error somehow, but there might be many characters passed
  to XDrawImageString16 and not drawing all of them would look bad. If
  it where only one an empty rectangle could be drawn instead.

One solution might be to wrap the XDrawImageString16 call in an
x_catch_errors, but that would be slow.  How about a solution that I
suggested some time ago, of simply ignoring non-fatal X errors (as
recommended in the X manual)?  No one responded to this thread.

  Currently, if Emacs receives an X protocol error and x_catch_errors
  has not been called, Emacs will kill itself (x_error_handler calls
  x_error_quitter, which calls x_connection_closed).  This seems
  unnecessary.

  Xlib defines two types of X error handlers.  The protocol error
  handler (for us, this is x_error_handler) is intended for non-fatal
  X protocol errors.  Fatal errors such as losing the connection to
  the X server invoke a different handler, the X IO error handler (for
  us, this is x_io_error_quitter), which really is supposed to kill
  Emacs.

  Currently, about half the uses of x_catch_errors in Emacs code occur
  where we want to make an Xlib call that can produce protocol
  errors---we don't want those to kill Emacs, but we don't actually
  care about whatever error messages are emitted.  It makes little
  sense to go through xmalloc'ing an error message storage stack,
  etc., for this.

  It seems to me cleaner to make the protocol error handler do nothing
  by default (rather than kill Emacs).  When x_catch_errors is on, we
  can carry out the current behavior, i.e., storing the error string
  etc.