bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains

[Lars Ingebrigtsen <larsi@gnus.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> Which means unfortunately that to see the form one needs to display
> the form piecemeal, one member at a time, using the xtype and the
> other x* commands...  Let me know if you need more detailed
> instructions.

Yes, that'd be appreciated.

(gdb) print form
$1 = XIL(0x7ffff211c263)
(gdb) pr form
#<INVALID_LISP_OBJECT 0x7ffff211c263>
(gdb) xtype form
Lisp_Cons
(gdb) xcons form
$2 = (struct Lisp_Cons *) 0x7ffff211c260
{
  u = {
    s = {
      car = XIL(0x2aaa9c41a9e0),
      u = {
        cdr = XIL(0),
        chain = 0x0
      }
    },
    gcaligned = 0xe0
  }
}
(gdb) xcar form
$3 = 0x0
(gdb) xcdr form
$4 = 0x0

Which doesn't seem ... right?

Anyway, the build failures (on the old commit) aren't 100% reproducible
now.  When running the bootstrap under gdb, it now currently just hangs,
so I have to C-c to get the backtrace.  It does hang (always) at the
same place (see below).

So I'm still guessing that there's memory corruption introduced by the
patch, so actually looking at the backtrace may not be very
productive...

Reloading stale subdirs.el
Loading /tmp/emacs/lisp/subdirs.el (source)...
^C
Thread 1 "bootstrap-emacs" hit Breakpoint 1, terminate_due_to_signal (
    sig=sig@entry=2, backtrace_limit=backtrace_limit@entry=40) at emacs.c:378
378	  signal (sig, SIG_DFL);
(gdb) bt
#0  terminate_due_to_signal
    (sig=sig@entry=2, backtrace_limit=backtrace_limit@entry=40) at emacs.c:378
#1  0x0000555555599698 in handle_fatal_signal (sig=sig@entry=2)
    at sysdep.c:1768
#2  0x00005555555996ae in deliver_process_signal
    (handler=0x55555559968d <handle_fatal_signal>, sig=2) at sysdep.c:1726
#3  deliver_fatal_signal (sig=2) at sysdep.c:1774
#4  0x00007ffff59e3140 in <signal handler called> ()
    at /lib/x86_64-linux-gnu/libpthread.so.0
#5  hash_lookup
    (h=0x7ffff1fbe518, key=XIL(0x555555c54b94), hash=hash@entry=0x0)
    at lisp.h:718
#6  0x00005555557392a2 in exec_byte_code
    (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:1415
#7  0x00005555556fdeb7 in Ffuncall (nargs=2, args=args@entry=0x7fffffffd6b8)
    at eval.c:2809
#8  0x0000555555736a78 in exec_byte_code
    (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:632
#9  0x00005555556fdeb7 in Ffuncall (nargs=1, args=args@entry=0x7fffffffe040)
--Type <RET> for more, q to quit, c to continue without paging--
    at eval.c:2809
#10 0x0000555555736a78 in exec_byte_code
    (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:632
#11 0x0000555555700e7f in apply_lambda
    (fun=XIL(0x7ffff1fc26f5), args=<optimized out>, count=4) at eval.c:2942
#12 0x00005555556fff03 in eval_sub (form=<optimized out>) at eval.c:2349
#13 0x0000555555701a29 in Feval
    (form=XIL(0x7ffff211c263), lexical=<optimized out>) at eval.c:2103


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no