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 #105 received at 33014 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: gazally <at> runbox.com, 33014 <at> debbugs.gnu.org, schwab <at> linux-m68k.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a
 thread's function
Date: Wed, 31 Oct 2018 17:33:56 +0200

> Cc: Gemini Lasswell <gazally <at> runbox.com>, 33014 <at> debbugs.gnu.org,
>  Stefan Monnier <monnier <at> iro.umontreal.ca>,
>  Andreas Schwab <schwab <at> linux-m68k.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Tue, 30 Oct 2018 21:49:46 -0700
> 
> > Any reason not to cherry-pick this to emacs-26?
> 
> No, once we fix it up. Although adding 'volatile' happened to work for Gemini's 
> compiler, it won't suffice in general as the C standard does not require 
> volatile variables to survive their last access (which is what the patch was 
> assuming). Furthermore, Fbyte_code bypasses that patch, so the bug could still 
> occur even if 'volatile' cured the bug in the more-common code path.
> 
> A simple way to ensure that the constant vector survives GC is to have 
> exec_byte_code put the vector into a GC-visible slot. As it happens, there's a 
> spare slot that we can appropriate, so this won't cost us stack (or heap) space. 
> I installed the first attached patch into master to do that, and backported the 
> patch series into emacs-26 via the last two attached patches.

Thanks.

Previous Next

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