From xemacs-m  Fri Dec 27 07:49:25 1996
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5])
          by xemacs.cs.uiuc.edu (8.8.4/8.8.4) with SMTP
	  id HAA29660 for <xemacs-beta@xemacs.org>; Fri, 27 Dec 1996 07:49:24 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA11786; Fri, 27 Dec 1996 05:48:52 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id FAA16743; Fri, 27 Dec 1996 05:48:49 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id FAA26630; Fri, 27 Dec 1996 05:48:50 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id FAA01425; Fri, 27 Dec 1996 05:48:47 -0800
Date: Fri, 27 Dec 1996 05:48:47 -0800
Message-Id: <199612271348.FAA01425@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Raymond Toy <toy@rtp.ericsson.se>, Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@xemacs.org
Subject: Re: 20.0-b32 crash
In-Reply-To: <m2pvzx3w8u.fsf@altair.xemacs.org>
References: <7266.851627564@rtp.ericsson.se>
	<m2pvzx3w8u.fsf@altair.xemacs.org>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.97)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

>>>>> "Raymond" == Raymond Toy <toy@rtp.ericsson.se> writes:
Raymond> I was running GNUS and did something (sorry, I don't really
Raymond> know what happened) which caused the following crash.
Raymond> Traceback from gdb below:

Steven> Thanks for the report and backtrace Raymond.

Steven> #0  0xeec73e30 in kill ()
Steven> #1  0x88fdc in fatal_error_signal (sig=11) at /home/unix/toy/apps/xemacs-20.0-b32/src/emacs.c:194
Steven> #2  <signal handler called>
Steven> #3  0x1a2b48 in x_to_emacs_keysym_sunos_bug (return_value_sunos_bug=0xefffe3b4, event=0xefffe6f0, 
Steven>     simple_p=0) at /home/unix/toy/apps/xemacs-20.0-b32/src/event-Xt.c:647

Steven> Shoot.  That's right in the middle of the keysym code, which has been
Steven> changed recently, and in a kludge I cannot test.  Please try to
Steven> isolate what you were doing before the crash occurred.

Joy - I managed to reproduce this.

Steven> The keysym code now translates kp_something X11 keysyms to
Steven> kp-something the same as Emacs, and perhaps there's a problem I
Steven> haven't found with how I implemented that.

Nothing to do with that.

Steven> #ifdef HAVE_XIM
Steven>   int len;
Steven>   char buffer[64];
Steven>               ^^		(This crap speaks for itself)
Steven>   char *bufptr = buffer;

I'm responsible for this code.  In my defence, I'll point out that the
code does try to recover if the lookupstring requires more than 64
bytes, so it's not as crappy as it looks.

Unfortunately (from a maintenance point of view) key lookup can happen
in 3 different ways, depending on the value of the --with-xim flag.
In general, when XEmacs gets a key event, lookupstring can translate
that into a keysym, a string, neither, or both.

There may still be some unresolved design conflicts because old code
assumed that every key event translates into a unique keysym.

An historical note:  my first XIM implementation was --with-xim=xlib.
It works fine for me on Solaris, but others have had trouble getting
it working on other systems.  Many months later, I discovered the
XmIm* set of routines, that makes coding an application using XIM much
easier.  However, this requires Motif, so there is still a need for
--with-xim=xlib.  Wearing my Sun hat, however, I can assume the
presence of Motif, so I'm not going to be putting a lot of effort into
maintaining the code for --with-xim=xlib.  That's why, if you run
configure --with-mule,
it will use
--with-xim=motif if motif is detected,
else
--with-xim=no.

That is, --with-xim=xlib will never be autodetected, unless some
configure hint (either "--with-xim" or "with-xim=xlib") is provided.

Steven>  ...
Steven> #define LOOKUPSTRING \
Steven>   len = XmbLookupString \
Steven>     (FRAME_X_XIC (x_window_to_frame \
Steven> 		  (get_device_from_display (event->display), event->window)), \
Steven>      event, bufptr, bufsiz, &keysym, &status);
Steven>  ...
Steven>  LOOKUPSTRING;           <======== This is the line Xemacs choked on

This SUNOS_GCC_L0_BUG kludge in event-Xt.c is really annoying.  My
guess is that recent versions of gcc don't have this bug anymore, and
we can simply remove any code that mentions it without any trouble.
It is only defined if using gcc on a Sun.

Looking at the code, I see that `return' needs to be a MACRO if
SUNOS_GCC_L0_BUG is defined, so we need at least the following patch
if we don't get rid of SUNOS_GCC_L0_BUG entirely.

But I was able to reproduce the crash without using gcc.  So the
following patch may actually fix 2 bugs.  Ray, does this solve your
problem?  I bet it does.

Martin

*** /tmp/geta27060	Fri Dec 27 05:05:24 1996
--- event-Xt.c	Fri Dec 27 05:02:49 1996
***************
*** 640,646 ****
  #else /* XIM_XLIB */
  #define LOOKUPSTRING \
    len = XmbLookupString \
!     (FRAME_X_XIC (x_window_to_frame \
  		  (get_device_from_display (event->display), event->window)), \
       event, bufptr, bufsiz, &keysym, &status);
  #endif /* XIM_XLIB */
--- 640,646 ----
  #else /* XIM_XLIB */
  #define LOOKUPSTRING \
    len = XmbLookupString \
!     (FRAME_X_XIC (x_any_window_to_frame \
  		  (get_device_from_display (event->display), event->window)), \
       event, bufptr, bufsiz, &keysym, &status);
  #endif /* XIM_XLIB */
***************
*** 708,716 ****
              enqueue_Xt_dispatch_event (emacs_event);
            }
          Lstream_close (XLSTREAM (instream));
! 	return Qnil;
        }
!     case XLookupNone: return Qnil;
      case XBufferOverflow:
        bufptr = alloca (len+1);
        bufsiz = len+1;
--- 708,716 ----
              enqueue_Xt_dispatch_event (emacs_event);
            }
          Lstream_close (XLSTREAM (instream));
! 	return (Qnil);
        }
!     case XLookupNone: return (Qnil);
      case XBufferOverflow:
        bufptr = alloca (len+1);
        bufsiz = len+1;

