Re: transpose-regions

[Chong Yidong]

I managed to reproduce the problem.  My backtrace is a little
different, but it makes sense; probably Martin's debugger is confused,
maybe due to being out of sync with his sources.

Upon setting a breakpoint at wrong_type_argument, I obtained the
following backtrace:

(gdb) bt
#0  wrong_type_argument (predicate=138004297, value=142379640) at data.c:118
#1  0x081bb353 in Flength (sequence=142379640) at fns.c:180
#2  0x081bc272 in concat (nargs=1, args=0xbfec7350, target_type=Lisp_Cons, 
    last_special=0) at fns.c:610
#3  0x081bc0ab in Fcopy_sequence (arg=142379653) at fns.c:539
#4  0x08208837 in copy_properties (source=0x87cc888, target=0x87cc7e0)
    at intervals.c:110
#5  0x0820b9cf in graft_intervals_into_buffer (source=0x87cc888, 
    position=13049, length=45, buffer=0x8398540, inherit=0) at intervals.c:1846
....
(gdb) f 2
#2  0x081bc272 in concat (nargs=1, args=0xbfec7350, target_type=Lisp_Cons, 
    last_special=0) at fns.c:610
610           len = XFASTINT (Flength (this));
(gdb) p this
$1 = 142379653
(gdb) xtype
Lisp_Cons
(gdb) xcons
$2 = (struct Lisp_Cons *) 0x87c8a80
{
  car = 0x8234763, 
  u = {
    cdr = 0x87c8a78, 
    chain = 0x87c8a78
  }
}
(gdb) p 0x8234763
$3 = 136529763
(gdb) xtype
Lisp_String
(gdb) xstring
$4 = (struct Lisp_String *) 0x8234760
"DEAD"
(gdb) p Vdead
$5 = 136529763

The problem seems to be that a cons cell that has already been
garbage-collected is being passed to Fcopy_sequence during
copy_properties(), in intervals.c:106.  Where did this cons cell come
from?

  target->plist = Fcopy_sequence (source->plist);

Is the garbage collector somehow failing to account for cons cells
assigned to interval plists?