GNU bug report logs -
#33014
26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function
Previous Next
Reported by: Gemini Lasswell <gazally <at> runbox.com>
Date: Thu, 11 Oct 2018 05:32:01 UTC
Severity: normal
Tags: fixed
Found in version 26.1.50
Fixed in version 27.1
Done: Gemini Lasswell <gazally <at> runbox.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
> How do we know there's a reference to that vector on thread 7's stack?
> Could it be that there is no reference at all?
Yes it could be that the reference is getting optimized out. I asked
gdb for more detail on the stack frames for exec_byte_code and
funcall_lambda, and the arguments referring to the byte-code object and
its components do appear to be optimized out, see below. I also tried
adding 'volatile' to the declaration of the local variable 'fun' in
Ffuncall, and that made the bug go away.
Is there anything else I should be looking at before concluding that
this is the problem? And if it is, what is the best way to fix it?
lisp.h:2241: Emacs fatal error: assertion failed: HASH_TABLE_P (a)
[Switching to Thread 0x7f6eca4b9700 (LWP 17729)]
Thread 7 "builder 0" hit Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6,
backtrace_limit=backtrace_limit <at> entry=2147483647) at emacs.c:369
369 {
(gdb) bt
#0 terminate_due_to_signal (sig=sig <at> entry=6,
backtrace_limit=backtrace_limit <at> entry=2147483647) at emacs.c:369
#1 0x00000000005a7159 in die (msg=msg <at> entry=0x67b132 "HASH_TABLE_P (a)",
file=file <at> entry=0x678c85 "lisp.h", line=line <at> entry=2241) at alloc.c:7094
#2 0x0000000000614685 in XHASH_TABLE (a=...) at lisp.h:2241
#3 exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=...,
nargs=nargs <at> entry=0, args=<optimized out>,
args <at> entry=0x16eac38 <bss_sbrk_buffer+9926040>) at bytecode.c:1403
#4 0x00000000005cdd32 in funcall_lambda (fun=XIL(0x7f6eca4b8470),
nargs=nargs <at> entry=0, arg_vector=0x16eac38 <bss_sbrk_buffer+9926040>,
arg_vector <at> entry=0x1574c58 <bss_sbrk_buffer+8394168>) at eval.c:3057
#5 0x00000000005ca54b in Ffuncall (nargs=nargs <at> entry=1,
args=args <at> entry=0x1574c50 <bss_sbrk_buffer+8394160>) at eval.c:2870
#6 0x000000000064680b in invoke_thread_function () at thread.c:684
#7 0x00000000005c964f in internal_condition_case (
bfun=bfun <at> entry=0x6467d0 <invoke_thread_function>, handlers=...,
handlers <at> entry=XIL(0xc3c0), hfun=hfun <at> entry=0x6466f0 <record_thread_error>)
at eval.c:1373
#8 0x00000000006471a1 in run_thread (state=0x1574c30 <bss_sbrk_buffer+8394128>)
at thread.c:723
#9 0x00007f6eea5cb5a7 in start_thread ()
from /nix/store/fg4yq8i8wd08xg3fy58l6q73cjy8hjr2-glibc-2.27/lib/libpthread.so.0
#10 0x00007f6ee9c6622f in clone ()
from /nix/store/fg4yq8i8wd08xg3fy58l6q73cjy8hjr2-glibc-2.27/lib/libc.so.6
(gdb) set print frame-arguments all
(gdb) info frame 3
Stack frame at 0x7f6eca4b87d0:
rip = 0x614685 in exec_byte_code (bytecode.c:1403); saved rip = 0x5cdd32
called by frame at 0x7f6eca4b87d0, caller of frame at 0x7f6eca4b87d0
source language c.
Arglist at 0x7f6eca4b87c0, args: bytestr=<optimized out>,
vector=<optimized out>, maxdepth=<optimized out>,
args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>,
args <at> entry=0x16eac38 <bss_sbrk_buffer+9926040>
Locals at 0x7f6eca4b87c0, Previous frame's sp is 0x7f6eca4b87c8
Saved registers:
rbx at 0x7f6eca4b8798, rbp at 0x7f6eca4b87c0, r12 at 0x7f6eca4b87a0,
r13 at 0x7f6eca4b87a8, r14 at 0x7f6eca4b87b0, r15 at 0x7f6eca4b87b8
(gdb) info frame 4
Stack frame at 0x7f6eca4b87d0:
rip = 0x5cdd32 in funcall_lambda (eval.c:3057); saved rip = 0x64680b
tail call frame, caller of frame at 0x7f6eca4b87d0
source language c.
Arglist at unknown address.
Locals at unknown address, Previous frame's sp is 0x7f6eca4b87d0
This bug report was last modified 6 years and 197 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.