GNU bug report logs - #33014
26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function

Previous Next

Full log

Message #47 received at 33014 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: gazally <at> runbox.com
Cc: 33014 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#33014: 26.1.50; 27.0.50;
 Fatal error after re-evaluating a thread's function
Date: Tue, 16 Oct 2018 22:38:05 +0300

> Date: Tue, 16 Oct 2018 22:25:21 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 33014 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
> 
> > - The value of 'fun' in Ffuncall after it is used as an argument for
> >   funcall_lambda.
> > 
> > - The value of 'fun' in funcall_lambda after it is used to calculate
> >   the arguments to exec_byte_code.
> > 
> > - The value of 'vector' in exec_byte_code after the calculation of
> >   vectorp.
> 
> There are calling frames as well.  For GC to pay attention to a Lisp
> object, it is enough to have that object _somewhere_ on the stack.

And btw, 'fun' is not the object we should be tracing in this case.
We should be tracing the bytecode that is being run, either the entire
vector or some of its elements.  AFAIU, that is the bytecode of the
thread function, which I think is the one called here:

> #11 0x00000000005cdd32 in funcall_lambda (fun=XIL(0x7fecdacdc468), nargs=nargs <at> entry=0, arg_vector=0x16eac38 <bss_sbrk_buffer+9926040>, 
>     arg_vector <at> entry=0x1578c58 <bss_sbrk_buffer+8410552>) at eval.c:3057
> #12 0x00000000005ca54b in Ffuncall (nargs=nargs <at> entry=1, args=args <at> entry=0x1578c50 <bss_sbrk_buffer+8410544>) at eval.c:2870
> #13 0x000000000064680b in invoke_thread_function () at thread.c:684

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.