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

Previous Next

Package: emacs;

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


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gemini Lasswell <gazally <at> runbox.com>
Cc: 33014 <at> debbugs.gnu.org
Subject: Re: bug#33014: 26.1.50; 27.0.50;
 Fatal error after re-evaluating a thread's function
Date: Fri, 12 Oct 2018 11:12:17 +0300
> From: Gemini Lasswell <gazally <at> runbox.com>
> Date: Wed, 10 Oct 2018 22:30:29 -0700
> 
> When I run some byte-compiled code which creates some threads, and then,
> while a thread is blocked, interactively evaluate the function which
> was used to create that thread, Emacs has a fatal error or segmentation
> fault when the thread becomes unblocked.

Can you please make a smaller stand-alone test case, which doesn't
require patching Emacs?  That will make it much easier to try
reproducing the problem.

> Thread 7 (Thread 0x7f1cd4dec700 (LWP 21837)):
> #0  terminate_due_to_signal (sig=sig <at> entry=6,
>     backtrace_limit=backtrace_limit <at> entry=2147483647) at emacs.c:369
> #1  0x00000000005a4d99 in die (msg=msg <at> entry=0x678d52 "HASH_TABLE_P (a)",
>     file=file <at> entry=0x6768a5 "lisp.h", line=line <at> entry=2241) at alloc.c:7094
> #2  0x00000000006122b5 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  0x00000000005cb972 in funcall_lambda (fun=..., nargs=nargs <at> entry=0,
>     arg_vector=0x16eac38 <bss_sbrk_buffer+9926040>,
>     arg_vector <at> entry=0x158ec58 <bss_sbrk_buffer+8500664>) at eval.c:3057
> #5  0x00000000005c818b in Ffuncall (nargs=nargs <at> entry=1,
>     args=args <at> entry=0x158ec50 <bss_sbrk_buffer+8500656>) at eval.c:2870
> #6  0x000000000064443b in invoke_thread_function () at thread.c:684
> #7  0x00000000005c728f in internal_condition_case (
>     bfun=bfun <at> entry=0x644400 <invoke_thread_function>, handlers=...,
>     handlers <at> entry=XIL(0xc3c0), hfun=hfun <at> entry=0x644320 <record_thread_error>)
>     at eval.c:1373
> #8  0x0000000000644dd1 in run_thread (state=0x158ec30 <bss_sbrk_buffer+8500624>)

Can you show the Lisp backtrace of this thread?  Also, what is the
offending object 'a' in this frame:

> #2  0x00000000006122b5 in XHASH_TABLE (a=...) at lisp.h:2241

and what was its parent object in the calling frame?

Thanks.




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.