From xemacs-m  Sun Jun 22 11:05:37 1997
Received: from jagor.srce.hr (hniksic@jagor.srce.hr [161.53.2.130])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id LAA16850
	for <xemacs-beta@xemacs.org>; Sun, 22 Jun 1997 11:05:36 -0500 (CDT)
Received: (from hniksic@localhost)
          by jagor.srce.hr (8.8.5/8.8.4)
	  id SAA21419; Sun, 22 Jun 1997 18:05:36 +0200 (MET DST)
To: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: `skip_debugger'
X-Attribution: Hrv
X-Face: Mie8:rOV<\c/~z{s.X4A{!?vY7{drJ([U]0O=W/<W*SMo/Mv:58:*_y~ki>xDi&N7XG
        KV^$k0m3Oe/)'e%3=$PCR&3ITUXH,cK>]bci&<qQ>Ff%x_>1`T(+M2Gg/fgndU%k*ft
        [(7._6e0n-V%|%'[c|q:;}td$#INd+;?!-V=c8Pqf}3J
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 22 Jun 1997 18:05:35 +0200
Message-ID: <kigu3iqpqr4.fsf@jagor.srce.hr>
Lines: 91
X-Mailer: Gnus v5.4.59/XEmacs 20.3(beta8) - "Copenhagen"

Now, this is becoming amusing.  Please take a look at the following
backtrace (sent to me by Steve):

#95805 0x8079a33 in Fcar (list={s = {type_mark = 8, val = -67109627}, gu = {
        type = Lisp_Int, markbit = 1, val = 201325829}, i = -1073754024, 
      v = 0xbfffd058, cv = 0xbfffd058}) at /usr/src/xemacs-20.0/src/data.c:134
#95806 0x813e119 in print_error_message (data={s = {type_mark = 8, 
        val = -67109627}, gu = {type = Lisp_Int, markbit = 1, 
        val = 201325829}, i = -1073754024, v = 0xbfffd058, cv = 0xbfffd058}, 
    stream={s = {type_mark = 1, val = -130662912}, gu = {type = Lisp_Record, 
        markbit = 0, val = 137772544}, i = -2090606591, v = 0x8363e001, 
      cv = 0x8363e001}) at /usr/src/xemacs-20.0/src/print.c:630
#95807 0x813dff6 in Ferror_message_string (obj={s = {type_mark = 8, 
        val = -67109627}, gu = {type = Lisp_Int, markbit = 1, 
        val = 201325829}, i = -1073754024, v = 0xbfffd058, cv = 0xbfffd058})
    at /usr/src/xemacs-20.0/src/print.c:606
#95808 0x808deca in skip_debugger (conditions={s = {type_mark = 2, 
        val = -131971584}, gu = {type = Lisp_Cons, markbit = 0, 
        val = 136463872}, i = -2111545342, v = 0x82246002, cv = 0x82246002}, 
    data={s = {type_mark = 2, val = -129242244}, gu = {type = Lisp_Cons, 
        markbit = 0, val = 139193212}, i = -2067875902, v = 0x84beb7c2, 
      cv = 0x84beb7c2}) at /usr/src/xemacs-20.0/src/eval.c:498
#95809 0x808e001 in signal_call_debugger (conditions={s = {type_mark = 2, 
        val = -131971584}, gu = {type = Lisp_Cons, markbit = 0, 
        val = 136463872}, i = -2111545342, v = 0x82246002, cv = 0x82246002}, 
    sig={s = {type_mark = 5, val = -130824188}, gu = {type = -3, markbit = 0, 
        val = 137611268}, i = -2093187003, v = 0x833c8045, cv = 0x833c8045}, 
    data={s = {type_mark = 2, val = -129242260}, gu = {type = Lisp_Cons, 
        markbit = 0, val = 139193196}, i = -2067876158, v = 0x84beb6c2, 
      cv = 0x84beb6c2}, active_handlers={s = {type_mark = 2, 
        val = -130114532}, gu = {type = Lisp_Cons, markbit = 0, 
        val = 138320924}, i = -2081832510, v = 0x83e9c1c2, cv = 0x83e9c1c2}, 
    signal_vars_only=1, stack_trace_displayed=0xbfffd0e8, 
    debugger_entered=0xbfffd0e4) at /usr/src/xemacs-20.0/src/eval.c:570

Here, we have signal_call_debugger calling skip_debugger, calling
Ferror_message_string.  Now, skip_debugger is called with the
DATA argument being a cons.  But that same thingie somehow becomes a
Lisp_Int when reaching Ferror_message_string.  Now, I'd like to ask
you all: HOW DID THE DATA ARGUMENT GET CORRUPTED?

Here is the function involved:

static int
skip_debugger (Lisp_Object conditions, Lisp_Object data)
{
  Lisp_Object tail;
  int first_string = 1;
  Lisp_Object error_message;

  for (tail = Vdebug_ignored_errors; CONSP (tail); tail = XCDR (tail))
    {
      if (STRINGP (XCAR (tail)))
	{
	  if (first_string)
	    {
	      error_message = Ferror_message_string (data);
	      first_string = 0;
	    }
	  if (fast_lisp_string_match (XCAR (tail), error_message) >= 0)
	    return 1;
	}
      else
	{
	  Lisp_Object contail;

          for (contail = conditions; CONSP (contail); contail = XCDR (contail))
            if (EQ (XCAR (tail), XCAR (contail)))
	      return 1;
	}
    }

  return 0;
}

Obviously, Ferror_message_string is called only once, when XCAR(tail)
becomes a string for the first time.  But the DATA argument somehow
transmutes to a Lisp integer.  Just how is that possible?

I cannot repeat the problem Steve encounters.  To repeat it, you
should compile XEmacs using union type, and change skip_debugger to
what have the above definition.

Then try stepping through skip_debugger and finding when and why the
DATA argument ceases being anything but a cons.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Then...  his face does a complete change of expression.  It goes from
a "Vengeance is mine" expression, to a "What the fuck" blank look.

