Re: window decoration problem with sawfish and GNOME 2

[David Mosberger <davidm napali hpl hp com>]

>>>>> On Wed, 29 Oct 2003 11:24:15 -0800, John Harper <jsh unfactored org> said:

  John> Hi, On Oct 29, 2003, at 11:14 AM, David Mosberger wrote:
  >> OK, I'll look into this.  Since I'm working remotely today, I had
  >> to find a new way to debug this issue and that made me try Xnest
  >> (never used it before).  It works beautifully and that way it's
  >> much easier to see what's going on.  In particular, I now noticed
  >> that sawfish prints a bunch of "Bad argument" messages:

  >> Bad argument: #<subr make-vector>, 73786976294838206464, 1 Bad
  >> argument: #<subr make-vector>, 73786976294838206464, 1 Bad
  >> argument: #<subr make-vector>, 73786976294838206464, 1 Bad
  >> argument: #<subr make-vector>, 73786976294838206464, 1 Bad
  >> argument: #<subr make-vector>, 73786976294838206464, 1

  >> Do you think these might be related to the decoration problem?

  John> yes, almost certainly. I vaguely remember something similar
  John> happening on other 64 bit architectures, which has been
  John> fixed. It may be worth trying the version of librep from cvs
  John> to see if it fixes the problem ("cvs
  John> -d:pserver:anonymous anoncvs gnome org:/cvs/gnome login; cvs
  John> -d:pserver:anonymous anoncvs gnome org:/cvs/gnome co librep")

I tried with CVS librep and CVS sawfish, but no change.  If I set a
breakpoint at the first rep_signal_arg_error(), I get this backtrace:

(gdb) bt
#0  rep_signal_arg_error (obj=6917529027643193800, argNum=1) at lisp.c:2577
#1  0x200000000008c570 in Fmake_vector (size=6917529027643193800, 
    init=2305843009214783592) at lispcmds.c:835
#2  0x2000000000093ec0 in vm (code=6917529027643047200, 
    consts=6917529027642789056, argc=0, argv=0x60000fffffffb110, v_stkreq=5, 
    b_stkreq=4, s_stkreq=4) at lispmach.h:651
#3  0x200000000009a940 in rep_apply_bytecode (subr=6917529027642889248, 
    nargs=0, args=0x60000fffffffb110) at lispmach.h:505
#4  0x20000000000818a0 in apply (fun=6917529027642889248, 
    arglist=2305843009214783592, tail_posn=2305843009214783592) at lisp.c:1710
#5  0x2000000000081df0 in Ffuncall (args=6917529027643177616) at lisp.c:1776
#6  0x2000000000091550 in Fcall_hook (hook=2305843009214783592, 
    arg_list=6917529027642574752, type=6917546619827106224) at lispcmds.c:1934
#7  0x2000000000093fb0 in vm (code=6917529027642473392, 
    consts=6917529027642404768, argc=5, argv=0x60000fffffffb440, v_stkreq=5, 
    b_stkreq=1, s_stkreq=7) at lispmach.h:666
#8  0x2000000000094700 in vm (code=6917529027643046960, 
    consts=6917529027642997440, argc=1, argv=0x60000fffffffb600, v_stkreq=8, 
    b_stkreq=2, s_stkreq=3) at lispmach.h:505
#9  0x2000000000094700 in vm (code=6917529027643046928, 
    consts=6917529027642997712, argc=1, argv=0x60000fffffffb730, v_stkreq=5, 
    b_stkreq=2, s_stkreq=3) at lispmach.h:505
#10 0x200000000009a940 in rep_apply_bytecode (subr=6917529027642890288, 
    nargs=1, args=0x60000fffffffb730) at lispmach.h:505
#11 0x20000000000818a0 in apply (fun=6917529027642890288, 
    arglist=6917529027643179472, tail_posn=2305843009214783592) at lisp.c:1710
#12 0x2000000000081df0 in Ffuncall (args=6917529027643179456) at lisp.c:1776
#13 0x2000000000091550 in Fcall_hook (hook=2305843009214749024, arg_list=0, 
    type=2305843009214783592) at lispcmds.c:1934
#14 0x4000000000050500 in Fcall_window_hook (hook=6917529027642399008, 
    win=6917529027642399008, args=6917529027643207856, type=10)
    at windows.c:1241
#15 0x400000000004c9b0 in add_window (id=8388643) at windows.c:470
#16 0x400000000001a730 in map_request (ev=0x800023) at events.c:691
#17 0x4000000000051c00 in manage_windows () at windows.c:1494
#18 0x40000000000456a0 in inner_main (arg=2305843009214783592) at main.c:317
#19 0x20000000000657b0 in rep_call_with_barrier (
    callback= 0x4000000000059670: 0x40000000000455c0 <inner_main>, 
    arg=2305843009214783592, closed=1, in=0, out=0, data=0x0)
    at continuations.c:346
#20 0x4000000000045cb0 in main (argc=1610616831, argv=0x60000fffffffb870)
    at main.c:426

The "size" argument in the Fmake_vector() call is 0x60000000002039c8,
which isn't an INT (since bit 2 is 0), so clearly something is wrong
here.  Is there a good way to trace execution of the byte-code?  Or is
there a way to force non-byte-code execution?

	--david